Androids não podem usar RTE, e dispositivos iOS não conseguem alterar o modo do editor

Suporte Instalação
1

Para mim, isso parece um bug, mas aí eu veria um tópico sobre isso aqui. Então, se meu fórum for o único com esse problema, deve ser algo do meu lado.

Bom, de qualquer forma.

Meus usuários de Android não conseguem ver o teclado virtual ao usar o editor de texto rico. Quando mudam para Markdown, tudo funciona normalmente. iPads e iPhones (Safari/PWA, DiscourseHub) ficam travados no modo Markdown e não conseguem mudar para o editor de texto rico.

Isso começou há dois dias, imagino. Meus usuários tendem a esperar antes de me avisar que algo está quebrado.

O que mais… auto-hospedado, 2 contêineres, na versão mais recente e atualizado diariamente, e o mais novo tem agora 20 minutos de idade no momento em que estou escrevendo. O modo de segurança não ajuda.

Qual é meu próximo passo? O console e possíveis erros não são uma opção em dispositivos móveis.

2

São, mas você precisa conectar o dispositivo a um notebook.

Fiz isso com meu tablet (Android, problema o mesmo descrito acima) e vejo:

image
image571×161 12 KB

(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

O Prosemirror é o editor de texto rico (RTEditor). Mas não posso ajudar além de compartilhar a mensagem de erro que vejo.

Fora de tópico: Obrigado pela risada sobre sua categoria “Beijos e animais” (Infelizmente, a tradução em inglês diz ‘cats’ em vez disso, então vou me ater à versão em alemã :wink: )

image
image1072×613 57.9 KB
image
image1085×700 70.5 KB

3

Adicionei:

DISCOURSE_ENABLE_CORS: true

Depois, inicializei o web_only.yml e adicionei https://foorumi.katiska.eu e https://cdnfoorumi.katiska.eu em CORS origins.

Sem sucesso.

Então, executei:

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>

Não entendo o que estou vendo aqui, mas o problema está no S3 e nas minhas configurações lá? Se sim, por que isso começou recentemente? Um sintoma pode ser que, desde ontem, não consigo mais escrever notas nos quadros.

Mas, se o CORS é o problema, por que apenas esses estão afetados?

—
Por que, em nome dos deuses antigos e novos, a IA usou Küsse nesse contexto :rofl:

6

Não acho que tenham havido mudanças recentes no Discourse que causem isso. No entanto, o S3 tem uma peculiaridade de longa data com CORS, que pode fazer com que CDNs cacheiem uma versão do asset sem o cabeçalho Access-Control-Allow-Origin. E, se for um problema de cache ruim, isso poderia explicar por que afeta apenas alguns dos seus usuários (provavelmente com base na localização deles).

Se não me engano, o S3 só envia o cabeçalho Access-Control-Allow-Origin para solicitações que enviam um cabeçalho Origin (ou seja, aquelas vindas de um navegador web normal). Quando o Access-Control-Allow-Origin é omitido, ele não envia Vary: origin em sua resposta. E assim: se a primeira solicitação para um determinado asset for enviada de um contexto que não seja de navegador web (por exemplo, curl, ou algum crawler web), o CDN pode cacheiar a versão sem o cabeçalho CORS. Muito chato!

A configuração DISCOURSE_CORS não ajudará em nada aqui. Ela só é relevante para o servidor de aplicação, não para o S3.

Na nossa hospedagem, contornamos esse problema configurando o Cloudfront para adicionar Access-Control-Allow-Origin: * a todas as respostas. Isso garante que o comportamento estranho do S3 não possa causar o cacheamento de um resultado ruim.

Alternativamente, você pode configurar o Cloudfront para incluir o cabeçalho de solicitação Origin em sua chave de cache, o que manteria as respostas sem CORS separadas das respostas com CORS.

A Amazon tem uma série de documentações sobre CORS aqui. Eu tinha este link nas minhas anotações, que aparentemente era um tópico de fórum exatamente sobre essa questão… mas parece que eles o removeram :cry:

7

Mas eu não uso Cloudfront, então deve vir da AWS?

8

Tem certeza? :eyes:

❯ host cdnfoorumi.katiska.eu
cdnfoorumi.katiska.eu is an alias for djpzno7cbajfp.cloudfront.net.

Edição: para ficar claro, estamos falando do AWS Cloudfront aqui, não do Cloudflare (os nomes são muito parecidos! :sweat_smile:)

9

É, é verdade — claro, eu estou usando o AWS CloudFront :laughing: Se não me engano, é preciso usar um domínio próprio. Ou algo assim.

10

Exato — é necessário para um domínio personalizado e também deixa as coisas mais baratas (a saída via Cloudfront é mais barata que a saída direta do S3, se não me engano)

11

Primeiro, removi todas as referências ao S3 do arquivo web_only.yml. Fiz um rebuild e, por precaução, executei rake posts:rebake. Os problemas desapareceram, mas as imagens continuaram a ser servidas via CDN. Restabeleci o S3 e o problema voltou.

Abri o AWS e dei uma olhada nas configurações da distribution no CloudFront. Havia lá, pelo menos, um domínio com mais de 3 anos de idade, cujo TLD havia mudado. Achei estranho que qualquer coisa estivesse funcionando de alguma forma. Alterei as configurações conforme as recomendações do CloudFront e, em algum ponto, também configurei access-control-allow-origin: * (o que é bobo, pois torna o CORS inútil). No entanto, pela minha compreensão, esse cabeçalho já estava sendo servido pelo CloudFront.

Por precaução, fiz outro rebuild e testei. Não adiantou.

Como é possível que o cache esteja causando problemas, invalidei /assets/* e, por segurança, também /assets/br/*. Fiz outro rebuild e, desta vez, o problema foi corrigido.

Outro problema também foi resolvido. Desde o verão, tenho tido o problema Oops…, ou seja, erro 50x após o rebuild. Quando abro o safe-mode e desabilito os temas, consigo acessar o admin. Preciso desabilitar vários TCs, cerca de 20+, e o fórum volta a funcionar. Depois disso, posso habilitar esses componentes e tudo volta a funcionar.

Portanto, podemos concluir que tudo isso surgiu de problemas com o AWS CloudFront?

12

A coisa do Oops é bastante surpreendente - eu não esperaria que isso tivesse relação com o Cloudfront… Mas, se já está corrigido… ótimo! :sweat_smile:

Isso apenas significa “este ativo está permitido para uso em um contexto cross-site”. Provavelmente você não gostaria desse cabeçalho nas respostas HTTP reais do fórum. Mas, para ativos estáticos, que não requerem autenticação e não contêm nenhuma informação privada, está totalmente tudo bem. É exatamente assim que o sistema de CORS deve ser usado - para que os servidores controlem seletivamente quais respostas devem estar disponíveis em contextos cross-site.

Se você realmente quisesse, poderia definir Access-Control-Allow-Origin: my-forum.example.com. Mas, nesse caso, você terá problemas se um dia mudar o domínio do seu fórum.