Closed Ithanil closed 3 months ago
Hello @Ithanil
May I ask why this email fallback was removed?
This change broke our BBB-Setup, since we have an IDP configured for with pre-existing users and rely on this mechanism to set the external_id of a user that has not yet logged in via our IDP.
With this change, instead of a successful login, we get a generic error message and a support ticket...
Regards FSeifer
Hello @Ithanil
May I ask why this email fallback was removed?
This change broke our BBB-Setup, since we have an IDP configured for with pre-existing users and rely on this mechanism to set the external_id of a user that has not yet logged in via our IDP.
With this change, instead of a successful login, we get a generic error message and a support ticket...
Regards FSeifer
I'm sorry that the change broke your setup, that's why I proposed to use a config flag for this behavior. Regarding the rationale, see the corresponding issue that was linked above: https://github.com/bigbluebutton/greenlight/issues/5872
Don't fall back to email as identifier if no user with external_id found.
For more details see https://github.com/bigbluebutton/greenlight/issues/5872
On top of this change, I introduced the following mechanism for our setup, to allow users to log in if they received an email that was previously owned by a different external account (which has previously logged into Greenlight). Without this code, Greenlight will not create the new user due to conflicting email addresses.
This changes the email associated with that other account to a dummy value, which does not cause issues and will be updated on the next login. The only alternative would be to completely delete the other account in Greenlight.
@farhatahmad Let me know if you want this code in GL, maybe behind a config flag.