Los Android no pueden usar RTE y los dispositivos iOS no pueden cambiar el modo del editor

Para mí suena a un error, pero en ese caso vería un tema al respecto aquí. Así que, si mi foro es el único, entonces el problema debe estar de mi lado.

En fin.

Mis usuarios de Android no pueden ver el teclado virtual si usan el editor de texto enriquecido. Al cambiar a Markdown, todo funciona bien. Los iPads y iPhones (Safari/PWA, DiscourseHub) están atascados en Markdown y no pueden cambiar a RTE.

Creo que esto empezó hace dos días. Mis usuarios tienden a esperar antes de decirme que algo está roto.

¿Qué más… autoalojado, 2 contenedores, en la última versión y actualizado a diario, y el más nuevo tiene ahora 20 minutos de antigüedad en el momento de escribir esto; el modo seguro no ayuda.

¿Cuál es mi siguiente paso? La consola y los posibles errores no son una opción en los móviles.

Sí lo son, pero necesitas conectar el dispositivo con un portátil.

Lo hice con mi tableta (Android, el problema es el mismo que el descrito anteriormente) y veo:

(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 es el editor de texto enriquecido (RTE). Pero no puedo ayudar más allá de compartir el mensaje de error que veo.


Fuera de tema: Gracias por la risa sobre tu categoría de “Besos y animales” (Lamentablemente, la traducción al inglés dice ‘cats’ en su lugar, así que me quedaré con la alemana :wink: )

Añadí:

DISCOURSE_ENABLE_CORS: true

Luego, inicié web_only.yml y agregué a CORS origins https://foorumi.katiska.eu y https://cdnfoorumi.katiska.eu.

Sin suerte.

Entonces, ejecuté:

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>

No entiendo lo que veo aquí, pero ¿el problema es S3 y mis configuraciones allí? Si es así, ¿por qué empezó recientemente? Un síntoma podría ser que desde ayer no he podido escribir notas en los paneles.

Pero si CORS es el problema, ¿por qué solo se ven afectadas esas?


¿Por qué, en nombre de los dioses antiguos y nuevos, la IA usó Küsse en ese contexto :rofl:

No creo que haya habido cambios recientes en Discourse que hayan provocado esto. Sin embargo, S3 tiene una peculiaridad de larga data con CORS, que puede hacer que las CDN almacenen en caché una versión del recurso sin la cabecera Access-Control-Allow-Origin. Y si se trata de un problema de caché defectuosa, eso podría explicar por qué solo afecta a algunos de tus usuarios (probablemente en función de su ubicación).

Si no recuerdo mal, S3 solo sirve la cabecera Access-Control-Allow-Origin a las solicitudes que envían una cabecera Origin (es decir, aquellas que provienen de un navegador web normal). Cuando se omite Access-Control-Allow-Origin, no sirve Vary: origin en su respuesta. Y así: si la primera solicitud para un recurso dado se envía desde un contexto que no es un navegador web (por ejemplo, curl o algún rastreador web), la CDN puede almacenar en caché la versión sin la cabecera CORS. ¡Muy molesto!

La configuración DISCOURSE_CORS no servirá de nada aquí. Solo es relevante para el servidor de aplicaciones, no para S3.

En nuestro alojamiento, evitamos este problema configurando Cloudfront para que agregue Access-Control-Allow-Origin: * a todas las respuestas. Eso asegura que el comportamiento extraño de S3 no pueda causar que se almacene un resultado incorrecto en caché.

Alternativamente, podrías configurar Cloudfront para incluir la cabecera de solicitud Origin en su clave de caché, lo que mantendría separadas las respuestas sin CORS de las respuestas con CORS.

Amazon tiene un montón de documentación sobre CORS aquí. Tenía este enlace en mis notas, que aparentemente era un hilo de foro sobre exactamente este problema… pero parece que lo eliminaron :cry:

Pero yo no uso Cloudfront, así que ¿debe provenir de AWS?

¿Estás seguro? :eyes:

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

Edición: para aclarar, estamos hablando de AWS Cloudfront aquí, no de Cloudflare (¡los nombres son súper parecidos! :sweat_smile:)

Sí, es cierto — seguro que estoy usando AWS CloudFront :laughing: Si mal no recuerdo, es necesario usar un dominio propio. O algo así.

Sí, exactamente: es necesario para un dominio personalizado y además hace que las cosas sean más baratas (la salida de datos de Cloudfront es más barata que la salida directa de S3, si mal no recuerdo)