Is it possible to change users SSO's external_id after a DB migration?

Product Support

AI 生成的摘要

The discussion revolves around changing users’ SSO external_id after a database migration. caub encountered issues when external_id length changed from 16 to 24 characters, causing login conflicts due to cropping. They ask if existing users’ external_id can be updated post-migration while preserving their Discourse profiles. fefrei suggests deleting all external_id values so users can log in using their email, provided their email hasn’t changed. caub confirms they will try updating the external_id to NULL in the database. simon clarifies that external_id is stored in the single_sign_on_records table and recommends using the Rails console to destroy all records with SingleSignOnRecord.destroy_all, which will allow new SSO records to be created based on email upon login, as long as require_activation is not enabled.

1

First I had issues with the external_id field on SSO, because they were all initially strings of length 16, and later I stored 24chars strings, but it completely messed up, you could get logged under a different user, it seems it cropped the external_id length, but that was hard to debug.

So I make sure to keep external_id with the same length, it’s not really practical, why not using a TEXT column type for it?

And my question is also, can I update the external_id of existing users, after doing a DB migration on my external site that provides SSO? and allow those users to keep their existing discourse profile when they’ll log in

Thanks for that good work

2

The easiest way might be to simply delete all external IDs – when your users try to sign in again, Discourse will use the email address to find the right account. (This won’t work if the users change their email address in the meantime!)

3

Thanks a lot,

So I’ll try to do a UPDATE user_table_name SET external_id=NULL, in DB thanks

5

The external_id saved to the single_sign_on_records table. You can delete all records from this table by entering the rails console and running

SingleSignOnRecord.destroy_all

As long as you are not setting require_activation to true in the SSO payload, after deleting your site’s SSO records, new SSO records will be created for your users based on their email address when they login with SSO.