Currently the CROWD Plugin does working correct when allowing custom usernames (read: Allow users to change username) via their Rocketchat user settings. It is quite a common feature to use this custom name as a mention name.
Additionally the crowd plugin does not allow to login via email (even if the login UI suggests it would work), nor specifically the crowd_username (if the username has been changed), but only by the username in the current implementation.
This means that after changing username in Rocketchat, the Crowd login will stop working (since the new username is not available in Crowd). Therefore the Crowd plugin redirects to the fallback login handler, which then logins the user locally via the stored hashed password.
A crowd sync will additionally override the custom usernames to their crowd_username pendants on syncing.
Furthermore the login does not allow to use the email address - the sync on the other hand also tries to sync on email address basis. This is not a consistent behaviour.
Steps to reproduce:
Enable Crowd authentication
Allow users to change their username under Accounts
Login via your crowd username
Change your username to something else
When logging in with your new rocketchat username you will be redirected to the fallback login, but not login via crowd
On sync your rocketchat username will be reset again to the crowd username
Expected behavior:
User can change is username in Rocketchat (if allowed in Account Settings and also in Crowd Settings)
User is able to login via Rocketchat username, crowd_username and email
On Crowd Sync and Login, the Rocketchat username is maintained as long as an option in the Crowd settings does allow a custom Rocketchat username.
If this option is disabled, the usernames should be reset to their crowd pendants.
Additional a local user (e.g. admin backup) should initially not be tried to be logged in via Crowd, but redirected to the fallback login in the first place
Actual behavior:
See steps to reproduce
Server Setup Information:
Version of Rocket.Chat Server: <=0.73.x
This is a code issue. Therefore it does not make sense to provide
Operating System:
Deployment Method:
Number of Running Instances:
DB Replicaset Oplog:
NodeJS Version:
MongoDB Version:
Additional context
In our specific case, the crowd_username is equal to the user's email address. This is not optimal specifically to us, but in general others may also give their users the ability to use nicknames in the chat tool, which should not be propagated to other applications connected to the crowd instance
Description:
Currently the CROWD Plugin does working correct when allowing custom usernames (read: Allow users to change username) via their Rocketchat user settings. It is quite a common feature to use this custom name as a mention name.
Additionally the crowd plugin does not allow to login via email (even if the login UI suggests it would work), nor specifically the crowd_username (if the username has been changed), but only by the username in the current implementation.
This means that after changing username in Rocketchat, the Crowd login will stop working (since the new username is not available in Crowd). Therefore the Crowd plugin redirects to the fallback login handler, which then logins the user locally via the stored hashed password.
A crowd sync will additionally override the custom usernames to their crowd_username pendants on syncing.
Furthermore the login does not allow to use the email address - the sync on the other hand also tries to sync on email address basis. This is not a consistent behaviour.
Steps to reproduce:
Expected behavior:
Actual behavior:
See steps to reproduce
Server Setup Information:
This is a code issue. Therefore it does not make sense to provide
Additional context
In our specific case, the crowd_username is equal to the user's email address. This is not optimal specifically to us, but in general others may also give their users the ability to use nicknames in the chat tool, which should not be propagated to other applications connected to the crowd instance
Relevant logs: