No login is possible after recovery a Discourse Backup on a new server

Hi,

I have recovered a Discourse Backup on a new VM.
The recovery itself seems to work. I see the the correct start GUI.

If I try to log in I receive an unknown error:

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)

Do you have any idea how to solve this issue?

Regards

I.

try resetting your password

I have tried it, it does not work however …

I think e-mail messages has been deactivated in the old installation (I recovered the backup of it.)

I.

Try to check if force_https is enabled using the console

SiteSetting.force_https

If it is false, set it to true

SiteSetting.force_https = true

1 Like

You mean, within the docker container or in VM bash?

Within Docker. Do this in your VM

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

Thank you, it was however already “true”:

image

Perhaps it has to be set to false (I do not have a certificate) OR we have to use the correct domain. (it is not “CNAMEd” yet)

HTTPS is not activated in YAML file.

Why not? Let’s Encrypt gives you one for free.

If you’re trying to use an IP without a host name, that is your problem. You must use a hostname.

If you’re not using https then it should be set to false indeed.

The Domain of the “productive” System ist “https://deinbalkonnetz.de” (hosted @discourse.). we have moved this to an internal VM still having the domain “discourse.itas-karlsruhe.de”. This domain (without HTTPS support) is still used in the app.yml.

Which is the correct order to move Discourse?

#1 forwarding the productive domain to the VM?
#2 changing app.yml to the final domain AND activate lets encrypt in the same time?

Please confirm!

Thank you.

I.

If you’re leaving discourse.org hosting then you should first cancel your subscription so that uploads get included in your backup. Otherwise, your backup will just point to uploads on their S3/CDN.

I recommend that you do your testing on a server with a public IP, or at least one with a valid https certificate (which is harder to configure on a private IP).

When you’re ready to move, you’ll need to change the DNS for your server and rebuild to get the let’s encrypt certificate, so you’ll be in limbo for a bit while DNS propagates.

Ok. Thank you very much.

If you’re leaving discourse.org hosting then you should first cancel your subscription so that uploads get included in your backup. Otherwise, your backup will just point to uploads on their S3/CDN.

I have requested a new backup …

I recommend that you do your testing on a server with a public IP, or at least one with a valid https certificate (which is harder to configure on a private IP).

I will deactivate HTTPS in “rail c” just to be able to log in. After log in I will check if the lets encrypt addin is activated (or it has to be made via app.yml)? If it is activated I will activate https for the temporary domain. If everything works we forward the final domain to the VM and rebuild the app with that domain.

I think it is a proper roadmap … right?