내 생각엔 버그인 것 같은데, 그러면 여기에서 관련 주제를 볼 수 있을 텐데. 내 포럼이 유일한 경우라면, 이건 내 쪽에서 발생한 문제일 수밖에 없다.
어쨌든.
안드로이드 사용자는 리치 텍스트 에디터를 사용할 때 가상 키보드를 볼 수 없다. 마크다운으로 바꾸면 모든 것이 정상이다. iPad와 iPhone(Safari/PWA, DiscourseHub)은 마크다운으로 고정되어 있고 RTE로 변경할 수 없다.
이 문제는 이틀 전부터 시작된 것으로 추정된다. 내 사용자들이 무언가가 깨졌다고 나에게 말하기 전에 기다리는 경향이 있기 때문이다.
그 외에는… 자체 호스팅, 2컨테이너 구성, 최신 버전이며 매일 업그레이드하고 있고, 글 작성 시점 기준으로 최신 버전은 20분 전 것이다. safe-mode를 켜도 도움이 되지 않는다.
다음 단계는 무엇인가? 모바일에서는 콘솔과 가능한 오류를 확인하는 것이 불가능하다.
확인할 수는 있지만, 장치를 노트북에 연결해야 합니다.
저도 태블릿(Android, 위에서 설명한 것과 동일한 문제)으로 이렇게 해보았는데, 다음과 같은 내용을 확인했습니다.
(index):1 Access to script at 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js' from origin 'https://foorumi.katiska.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
prosemirror-editor-opfbo6zd.digested.js:1 GET https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js net::ERR_FAILED 200 (OK)
d-editor.gjs:212 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://cdnfoorumi.katiska.eu/assets/br/prosemirror-editor-opfbo6zd.digested.js
Prosemirror는 RTEditor입니다. 하지만 제가 볼 수 있는 오류 메시지를 공유하는 것 이상으로는 더 이상 도움을 드릴 수 없습니다.
부수적인 이야기: “Kisses and animals”(키스와 동물) 카테고리에 대한 웃음 감사합니다. (불행히도 영어 번역에는 ‘cats’(고양이)라고 되어 있어서, 독일어 버전을 유지할게요 
)
다음 내용을 추가했습니다:
DISCOURSE_ENABLE_CORS: true
그 후 web_only.yml을 부트스트랩하고 CORS origins에 https://foorumi.katiska.eu와 https://cdnfoorumi.katiska.eu를 추가했습니다.
하지만 해결되지 않았습니다.
그런 다음 다음 명령을 실행해 보았습니다:
curl -sI -H 'Origin: https://foorumi.katiska.eu' 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedllgv.digested.js'
HTTP/2 403
content-type: application/xml
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD
access-control-max-age: 3000
server: AmazonS3
date: Thu, 10 Sep 2026 14:13:35 GMT
x-cache: Error from cloudfront
via: 1.1 <characters>.cloudfront.net (CloudFront)
x-amz-cf-pop: HEL51-P1
x-amz-cf-id: <characters>
여기서 보이는 것이 무엇을 의미하는지 이해가 안 되는데, 문제가 S3와 거기에 설정한 내 설정 때문일까요? 그렇다면 왜 최근에 갑자기 문제가 발생했을까요? 하나의 증상으로, 어제부터 보드 노트(boards-notes)를 더 이상 작성할 수 없었습니다.
하지만 CORS가 문제라면 왜 오직 그것들만 영향을 받는 걸까요?
—
고신과 신신(신과 구신)의 이름으로, 왜 AI는 그 맥락에서 Küsse를 사용했는지 궁금합니다 
이 문제를 일으킬 만한 최근의 Discourse 변경 사항은 없다고 생각합니다. 하지만 S3에는 CORS와 관련된 오래된 특이한 문제가 있으며, 이로 인해 CDN이 Access-Control-Allow-Origin 헤더가 없는 자산 버전을 캐시할 수 있습니다. 그리고 이것이 잘못된 캐시 문제라면, 왜 일부 사용자(아마도 위치 기반일 가능성이 높습니다)에게만 영향을 미치는지 설명할 수 있습니다.
기억이 맞다면, S3는 Origin 헤더를 전송하는 요청(즉, 일반적인 웹 브라우저에서 오는 요청)에만 Access-Control-Allow-Origin 헤더를 제공합니다. Access-Control-Allow-Origin가 생략된 경우, 응답에 Vary: origin을 제공하지 않습니다. 따라서: 특정 자산에 대한 첫 번째 요청이 웹 브라우저가 아닌 컨텍스트(예: curl 또는 일부 웹 크롤러)에서 전송되면, CDN은 CORS 헤더가 없는 버전을 캐시할 수 있습니다. 정말 귀찮은 문제입니다!
여기서는 DISCOURSE_CORS 설정이 전혀 도움이 되지 않습니다. 그것은 S3가 아니라 애플리케이션 서버에만 관련이 있기 때문입니다.
우리의 호스팅에서는 Cloudfront를 구성하여 모든 응답에 Access-Control-Allow-Origin: *를 추가함으로써 이 문제를 우회합니다. 이렇게 하면 S3의 특이한 동작이 잘못된 결과가 캐시되는 것을 방지할 수 있습니다.
또는, Cloudfront를 구성하여 캐시 키에 Origin 요청 헤더를 포함하도록 할 수도 있습니다. 그러면 non-CORS 응답과 CORS 응답이 별도로 유지됩니다.
Amazon은 CORS에 대한 문서를 여기에 많이 제공하고 있습니다. 제 노트에는 정확히 이 문제에 대한 포럼 스레드였던 것으로 보이는 이 링크가 있었는데, Apparently 삭제된 것 같습니다 
하지만 저는 Cloudfront을 사용하지 않으므로, AWS에서 오는 것이겠죠?
확신하나요? 
❯ host cdnfoorumi.katiska.eu
cdnfoorumi.katiska.eu is an alias for djpzno7cbajfp.cloudfront.net.
수정: 명확히 하자면, 여기서 이야기하는 것은 Cloudflare가 아니라 AWS Cloudfront입니다. (이름이 매우 비슷하거든요! 
)
맞아요, 그거 맞아요 — AWS CloudFront을 쓰고 있긴 해요 
기억이 맞다면, 자체 도메인을 사용해야 하는 것 같아요. 아니면 뭐 그런 거요.
네, 정확합니다. 커스텀 도메인에 필수적인 요소일 뿐만 아니라, 비용도 절감됩니다. 제 기억이 맞다면 CloudFront의 egress 비용이 직접 S3 egress보다 저렴하거든요.
Ensimmäiseksi poistin web_only.yml-tiedostosta kaikki S3-viittaukset. Suoritin rebuildin ja varmuuden vuoksi myös rake posts:rebake-komennon. Ongelmat poistuivat, mutta kuvat tulivat edelleen CDN:n kautta. Palautin S3:n, ja ongelma palasi.
Avasin AWS-konsolin ja vilkaisin CloudFrontin distribution-asetukset. Siellä oli ainakin kolme vuotta vanha domain, jonka TLD oli muuttunut. Pidän ihmeellisenä, että mikään on ylipäätään toiminut. Muutin asetuksia CloudFrontin suositusten mukaiseksi ja johonkin kohtaan asetin myös access-control-allow-origin: * (joka on älytöntä, koska se tekee CORS:ista turhan). Tosin ymmärtääkseni tuo header oli kuitenkin jo tarjoiltu CloudFrontin kautta.
Varmuuden vuoksi taas rebuild ja testaaminen. Ei auttanut.
Koska on mahdollista, että cache kiukuttelee, invalidisoin /assets/* ja varmuuden vuoksi myös /assets/br/*. Taas rebuild, ja nyt ongelma korjaantui.
Korjaantui toinenkin ongelma. Minulla on ollut kesästä asti ongelmana Oops… eli virhe 50x rebuildin jälkeen. Kun avaan safe-moden ja disabloin teemat, pääsen adminiin. Minun täytyy disabloida useampi TC, luokkaa 20+, ja foorumi herää henkiin. Sitten voin tehdä enable noille komponenteille, ja kaikki toimi taas.
Joten voidaanko vetää johtopäätös, että kaikki syntyi AWS CloudFrontin ongelmista?
Oops 관련 부분은 꽤 놀랍네요 - Cloudfront과 관련이 있을 거라고는 예상하지 못했습니다… 하지만 이제 수정되었다면… 좋습니다!
이것은 단순히 "이 자원이 사이트 간 컨텍스트에서 사용될 수 있다"는 의미입니다. 실제 포럼 HTTP 응답에는 이 헤더를 설정하고 싶지 않을 것입니다. 그러나 인증이 필요하지 않고 개인 정보를 포함하지 않는 정적 자원의 경우, 완전히 문제가 없습니다. 이것이 바로 CORS 시스템이 의도한 사용 방식입니다 - 서버가 어떤 응답이 사이트 간에 사용 가능해야 하는지 선택적으로 제어하는 것이죠.
원한다면 Access-Control-Allow-Origin: my-forum.example.com으로 설정할 수도 있습니다. 하지만 그렇게 하면 나중에 포럼 도메인을 변경할 경우 문제가 발생할 것입니다.