No es posible iniciar sesión después de recuperar una copia de seguridad de Discourse en un nuevo servidor

Soporte
1

Hola,

He recuperado una copia de seguridad de Discourse en una nueva máquina virtual.
La recuperación en sí parece funcionar correctamente. Veo la interfaz gráfica de inicio adecuada.

Sin embargo, cuando intento iniciar sesión, recibo un error desconocido:

Processing by UsersController#create as */*
  Parameters: {"name"=>"Istvan XXXXXXX", "email"=>"istvan.XXXXXXXX@mailbox.org", "password"=>"[FILTERED]", "username"
=>"Istvan", "password_confirmation"=>"[FILTERED]", "challenge"=>"6662a14f4549a786ed0f37XXXXXX", "timezone"=>"Eur
ope/Berlin"}
Filter chain halted as :respond_to_suspicious_request rendered or redirected
Completed 200 OK in 3ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 1007)
Started POST "/login" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by StaticController#enter as HTML
  Parameters: {"username"=>"Istvan", "password"=>"[FILTERED]", "redirect"=>"/u/account-created"}
Redirected to http://discourse.XXXXXXXXX/u/account-created
Completed 302 Found in 2ms (ActiveRecord: 0.0ms | Allocations: 512)
Started GET "/u/account-created" for 172.17.0.1 at 2021-10-13 13:37:31 +0000
Processing by UsersController#account_created as HTML
  Rendered default/empty.html.erb within layouts/application (Duration: 0.1ms | Allocations: 11)
  Rendered layout layouts/application.html.erb (Duration: 60.6ms | Allocations: 36879)
Completed 200 OK in 81ms (Views: 62.1ms | ActiveRecord: 0.0ms | Allocations: 39906)
Started GET "/session/csrf" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 4ms (Views: 2.0ms | Allocations: 602)
Started POST "/session" for 172.17.0.1 at 2021-10-13 13:37:48 +0000
Processing by SessionController#create as */*
  Parameters: {"login"=>"Istvan", "password"=>"[FILTERED]", "second_factor_method"=>"1", "timezone"=>"Europe/Berlin"
}
Can't verify CSRF token authenticity.
  Rendered text template (Duration: 0.0ms | Allocations: 1)
Filter chain halted as :verify_authenticity_token rendered or redirected
Completed 403 Forbidden in 5ms (Views: 0.7ms | Allocations: 897)

image
image611×592 37 KB

¿Tienes alguna idea sobre cómo resolver este problema?

Saludos,

I.

2

intenta restablecer tu contraseña

3

Lo he probado, pero no funciona…

image
image800×432 31 KB

Creo que los mensajes de correo electrónico se han desactivado en la instalación anterior (he recuperado su copia de seguridad).

Yo.

4

Intenta verificar si force_https está habilitado usando la consola

SiteSetting.force_https

Si es falso, cámbialo a verdadero

SiteSetting.force_https = true

5

¿Te refieres dentro del contenedor de Docker o en la bash de la VM?

6

Dentro de Docker. Haz esto en tu VM

cd /var/discourse/
./launcher enter app
rails c
7

Gracias, sin embargo ya era “verdadero”:

image

Quizás deba establecerse en falso (no tengo un certificado) o debemos usar el dominio correcto (aún no tiene un registro CNAME).

HTTPS no está activado en el archivo YAML.

8

¿Por qué no? Let’s Encrypt te proporciona uno gratis.

Si estás intentando usar una dirección IP sin un nombre de host, ese es tu problema. Debes utilizar un nombre de host.

9

Si no estás usando HTTPS, entonces efectivamente debería establecerse en false.

10

El dominio del sistema “productivo” es “https://deinbalkonnetz.de” (alojado en discourse.). Hemos migrado esto a una máquina virtual interna que aún mantiene el dominio “discourse.itas-karlsruhe.de”. Este dominio (sin soporte HTTPS) sigue utilizándose en el archivo app.yml.

¿Cuál es el orden correcto para migrar Discourse?

#1 ¿Reenviar el dominio productivo a la máquina virtual?
#2 ¿Cambiar app.yml al dominio final Y activar Let’s Encrypt al mismo tiempo?

¡Por favor, confírmenlo!

Gracias.

I.

11

Si vas a dejar el alojamiento de discourse.org, primero debes cancelar tu suscripción para que las subidas se incluyan en tu copia de seguridad. De lo contrario, tu copia de seguridad solo apuntará a las subidas en su S3/CDN.

Recomiendo que realices las pruebas en un servidor con una dirección IP pública, o al menos uno con un certificado HTTPS válido (lo cual es más difícil de configurar en una IP privada).

Cuando estés listo para migrar, deberás cambiar los DNS de tu servidor y reconstruir para obtener el certificado de Let’s Encrypt, por lo que quedarás en un estado de espera mientras se propagan los cambios de DNS.

12

De acuerdo. Muchas gracias.

Si vas a dejar el alojamiento de discourse.org, primero debes cancelar tu suscripción para que las cargas se incluyan en tu copia de seguridad. De lo contrario, tu copia de seguridad solo apuntará a las cargas en su S3/CDN.

He solicitado una nueva copia de seguridad…

Recomiendo que realices las pruebas en un servidor con una dirección IP pública, o al menos con un certificado HTTPS válido (lo cual es más difícil de configurar en una IP privada).

Desactivaré HTTPS en “rail c” solo para poder iniciar sesión. Tras iniciar sesión, verificaré si el complemento de Let’s Encrypt está activado (¿o debe configurarse mediante app.yml?). Si está activado, habilitaré HTTPS para el dominio temporal. Si todo funciona, redirigiremos el dominio final a la VM y reconstruiremos la aplicación con ese dominio.

Creo que es una hoja de ruta adecuada… ¿verdad?

13

Hola,

tras desactivar HTTPS con SiteSetting.force_https = false, el sitio fue accesible y pude iniciar sesión como administrador del sitio.

He configurado Let’s Encrypt siguiendo los pasos descritos:
(Set up HTTPS support with Let's Encrypt)

Después de reconstruir el sitio, nada ha funcionado; ningún sitio era accesible en el navegador…

¿Existe alguna forma de verificar qué salió mal?

Saludos,

I.