Si mantuviste tu sesión, no experimentarás ningún problema. Sin embargo, si intentas iniciar sesión ahora, al hacer clic en “Iniciar sesión”, la URL cambia a: /auth/failure?message=csrf_detected y recibimos el mensaje de error: La autorización ha caducado o has cambiado de navegador. Por favor, inténtalo de nuevo..
¿Alguien sabe si hubo algún cambio reciente que pueda haber provocado esta situación?
Una pregunta de paso, ¿hay alguna forma de volver a una versión anterior? He estado buscando y el consenso es desactivar los plugins (o el plugin específico que causa el problema). Sin embargo, no puedo desactivar este porque es la forma en que mis usuarios inician sesión en la plataforma
Realmente no está soportado, pero si tienes una copia de seguridad, puedes eliminar el directorio de datos de PostgreSQL, agregar un commit en la línea de versión en app.yml, reconstruir y restaurar la copia de seguridad.
Sí, hice una copia de seguridad y estoy intentando reconstruir usando el SHA de la versión que tenía, ya que está funcionando de manera intermitente.
Por otro lado, aún tengo la versión más reciente estable intentando ver si podemos solucionarlo de alguna manera.
No sé si @david tiene algún consejo, como sugirió @codinghorror, pero estoy dispuesto a probar cualquier cosa, ya que mis usuarios no pueden acceder (a menos que hayan mantenido su sesión).
Actualización rápida: Intenté usar la versión de respaldo con una instantánea de la máquina tal como estaba en ese momento (antes de la actualización). Al hacer clic en “Iniciar sesión”, simplemente se recarga la página principal dos veces. Intenté reconstruir con el SHA exacto del commit que tenía en ese momento, pero no tuve suerte: error de Rake en la base de datos.
He estado buscando otros informes sobre el problema de LDAP y no parece haber ninguno. ¿Podría esto ser causado por una fuente externa?
Problema resuelto, se encontró la causa raíz; no estaba relacionada con Discourse (¡lo siento, chicos!). El problema fue que el certificado se actualizó y se sirvió a través de un HAP. Antes no utilizábamos un HAP y Discourse lo servía por sí mismo. Olvidamos este detalle, lo que provocó el error de CORS.
Lecciones aprendidas:
Revertir Discourse no es una opción; es mejor tener una copia de seguridad de toda la máquina (afortunadamente, en este caso sí la teníamos).
Todavía estoy investigando por qué fue tan difícil reconstruir con un SHA específico siguiendo las instrucciones que leí aquí; no pude hacerlo.
Es mejor siempre servir los certificados desde el HAP, pero no olvidarse de ello. (Como nota para cualquier otra persona: es necesario añadir el parámetro 'set-header X-Forwarded-Proto https', ya que Discourse tiene su propio NGINX, y ahí es donde fallaba).
El hecho de que nadie reportara el mismo problema (incluso considerando que este es un caso extremo, ya que el plugin no es oficial) apuntaba en esa dirección (comunidad tal como se pretendía :P).
El problema solo se manifestó tarde (hasta el punto de que no recordábamos el cambio de certificado) debido a la reconstrucción desencadenada por la actualización, momento en el cual falló.
