RocketChat / RocketChat/Rocket.Chat
Oauth user provisioning does not allow changing of username
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 46.1k
- Forks
- 13.9k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 130
Description
Description:
Already existing Oauth provisioned users do not change the username on subsequent logins after the Oauth username attribute has been changed.
Steps to reproduce:
- Set up a custom oauth login
- In the custom oauth config set the users to be defined by username ID, keyfield username and email to use email attribute
- Login and logout once as a test user
- Change custom oauth config to use email for both username and keyfield as well as email
- Login with a clean browser session again as the same test user
Expected behavior:
Username is replaced with the value from the provisioned email attribute.
Actual behavior:
The username does not get updated. The username remains as the original username ID instead of the provisioned email attribute.
Server Setup Information:
- Version of Rocket.Chat Server: 5.2.0
- Operating System: RHEL8
- Deployment Method: tar
- Number of Running Instances: 1
- DB Replicaset Oplog: Yes
- NodeJS Version: 14.19.3
- MongoDB Version: 4.4
Additional context
Background: We'd like to work around an issue of non working real names in message reactions by changing the username attribute to email instead of random numbers.
We understand that API calls to update usernames would probably will probably be a better method to achieve this. Regardless, this seems to be a feature bug as it is possible to change usernames successfully in LDAP configuration versus Oauth.
(And yes, it is an expensive operation, but Oauth providers or RC maintainers does this kind of operation in only a dire need so that is acceptable.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Start with the custom OAuth login and user-provisioning flow described in the reproduction steps, tracing the existing-user path after the username and keyfield configuration changes. Done means an existing provisioned user's username matches the updated email attribute on the next login, with coverage for the described sequence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- authentication
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100