Hi! I’m preparing to migrate some Discourse instances to new hosting. The plan is to set the old site read-only, take a backup, move that across to the new hosting and restore while updating the DNS settings (on a short TTL). This process is all taken from guides here and around. I’ve been doing some dry-runs on this, using a /etc/hosts file hack to simulate the DNS update (and with DNS over HTTPS disabled in the browser too). So far so good. However, despite being careful to close the browser on the ‘source’ site, then only opening it after complete migration on the ‘destination’ site, it forgets that it was logged in. Obviously I don’t want the site members to all be logged out over the migration. Where should I look or what am I missing here? The user I’m currently testing has Admin and is using 2FA, and the discourse containers are behind Nginx which terminates SSL, if that makes a difference to the problem. Thanks in advance for any pointers!

I’ve had this problem too and I’m keen to resolve it. Any pointers appreciated.

I think I’m going to try creating some test accounts without 2FA in case that has anything to do with it - very few site members use 2FA, so that might be acceptable it it’s just those sessions that get lost. Also I’ll check the source and destination servers are sync’d to NTP though they can’t be more than a few seconds off each other now I think. Other than that, I guess there’s always the source code to try and figure out what goes into the authentication token and could be causing a problem… :grimacing:

Your best would be to inform your users about the change and that they would be logged out and need to sign in again. Each server has their unique signature with the SSL in place. It will be less of a headache to make the user sign in again, than trying to change server settings. Just apologize for the inconvenience caused, but point out its for the better

[图片] IAmGav: Each server has their unique signature with the SSL in place. Is that the case though? How are session cookies affected by SSL “signatures” (especially when, in my case, the new and old hosts are using the same SSL certificate files, on the same domain name)?

[图片] IAmGav: Just apologize for the inconvenience caused, but point out its for the better While I have no problem apologizing to the members (:slightly_smiling_face:), I really want to avoid that scenario as I can see a couple of unfavorable side-effects: Members don’t log in again, and are less likely to participate in the forum in future Members forget their password and need help recovering their passwords Members forget their passwords and create new accounts, leaving lots of ‘zombie accounts’ on the forum and lost/confusing duplicate identities without User Notes or post history etc… The SSL bit all works fine in front of Discourse (even with the hosts file hack), which if you think about it, must be the case otherwise load-balancers would have problems. As far as I’m aware, Discourse doesn’t even know about the SSL as it is terminated at Nginx in this setup. I guess a different question is ‘is it possible to migrate a Discourse server to a new IP without logging everyone out?’ I had assumed it would be, but maybe that assumption was wrong… :frowning:

I know that I’ve definitely had forum sessions survive a backup & restore. I’m really not sure what’s going on here :frowning:

Session cookies are encrypted using a randomly generated secret key which, by default, is stored in redis. Redis data is not included in a backup so a new secret key is regenerated when you restore the site onto a new server. app/models/global_setting.rb 6e69c2513 # In Rails secret_key_base is used to encrypt the cookie store # the cookie store contains session data # Discourse also uses this secret key to digest user auth tokens # This method will # - use existing token if already set in ENV or discourse.conf # - generate a token on the fly if needed and cache in redis # - enforce rules about token format falling back to redis if needed You can manually set the secret key using an environment variable DISCOURSE_SECRET_KEY_BASE in your app.yml file. So you could try something like this to preserve sessions: On your existing server, enter the console and find the secret key from redis pry(main)> GlobalSetting.safe_secret_key_base => "5fb9dc98be368599e0a..." Add DISCOURSE_SECRET_KEY_BASE to the env: section of your app.yml on the old server, using the value you found in (1), and rebuild the app. In theory, if everything went right, Discourse should now use the value from the app.yml, and user sessions will persist. You can check the env variable is being used by running GlobalSetting.secret_key_base Make sure the app.yml on the new server has the same SECRET_KEY_BASE. When you restore the backup, the user sessions should persist I haven’t tested that flow, so if you plan to use it for a production forum make sure to test it out first! Side note: you absolutely should not share the secret key between multiple discourse instances. Possession of the secret key would allow someone to decrypt and modify their session cookie on a site, and could have very bad security consequences.

Excellent - this is something I shall try out on a sandbox instance. I’ll see if I can report back if it works or not :slight_smile: [图片] david: Side note: you absolutely should not share the secret key between multiple discourse instances. Understood. I am now pondering whether there should be a feature request for an option to export this key in backups? To me, losing all the sessions on a site would seem like a ‘very bad thing’ to happen as there are a few thousand accounts on the site. Practicing the migration has shown this problem, but I guess if the machine or Docker instance were lost for some reason, the key would be lost too and we’d be facing the same loss of sessions. Some note of this ‘feature’ on the migration topic might be good too: Move your Discourse Instance to a Different Server

[图片] TallTrees: I am now pondering whether there should be a feature request for an option to export this key in backups? It is a delicate balancing act between security and convenience. At the moment if someone manages to steal a discourse backup, they have all the data on the forum. But they do not have the ability to log in to the live forum. Passwords are hashed, api keys are hashed, and session cookies are encrypted. If we included the secret inside the backup, then anyone in possession of a backup could gain access to the live forum, and conduct phishing/fraud/etc. [图片] TallTrees: this is something I shall try out on a sandbox instance. I’ll see if I can report back if it works or not :slight_smile: Sounds great! Totally open to having a topic here on Meta explaining how to migrate from a redis secret key to an app.yml secret key. It could be linked from the ‘move to a different server’ topic.

[图片] david: At the moment if someone manages to steal a discourse backup, they have all the data on the forum. But they do not have the ability to log in to the live forum. The security of the default backups should also be improved too, in my humble opinion. While passwords and sessions may be hashed and protected, there could be a lot of other data in private messages and such which should still remain confidential. Particularly note that in our community forum we encourage people to use private messages to swap contact details and arrange sales or collections, rather than putting phone numbers and addresses in public places. The approach I’m taking to backups is to enter the instance, generate a backup, then immediately encrypt it with a public key using gpg. This renders the backup useless to anyone that doesn’t have the corresponding private key, which I store off the server and protected by a passphrase. That said, if the secret key for sessions doesn’t change, it only need to be backed up once, so a simple procedure for that is all that’s needed - and hopefully is what you’ve outlined above. I’ll give it a go and see if I can create that topic for you :slight_smile:

迁移主机时保留用户会话

产品支持安装

话题		回复	浏览量
Preserve user sessions when migrating to a new host Sysadmins migrations , how-to	0	1485	2020 年10 月 7 日
How to migrate Discourse Forum data (Topics, Chat, and Configuration) to another server Self-hosting	5	1869	2023 年6 月 7 日
Move your Discourse Instance to a Different Server Self-Hosting migrations , how-to	11	294412	2026 年8 月 11 日
How to switch Discourse servers? Self-hosting	6	1133	2023 年1 月 19 日
How do I move the discourse installed server to another server without loss? Self-hosting	4	1376	2023 年5 月 31 日

迁移主机时保留用户会话

相关话题