We have a number of users signed up via email, but now we want to move them all to a gitlab authentication (and obviously preserve their history).
If the users try to sign in with gitlab, it fails with an error mentioning no match with this auth type. If they try to sign up with gitlab, it fails with an error that the email address is already in use.
In an experimental setup we were able to directly set AuthService to ‘gitlab’ and AuthData to the appropriate gitlab ID, which worked fine. However, thou shalt not manually edit the database, so what is the right way to do this? I can’t see an option in the command-line tool.
Bumping this one - any ideas? This seems like an unsupported admin operation, am I right?
I have a lot of email signup users and I need to disable email sign in and get them on gitlab auth. Currently my best option seems to be the manual database change described above.
This isn’t supported as an admin feature right now, but users can switch the sign in method themselves from Account Settings > Security > Sign-in Method. (This requires both email and GitLab sign on to be enabled).
After all your users switch over you could then turn off email. We should probably think about adding admin features to help make this easier in the future, but this might work as a work around for now.
Ah, thanks. That’s probably not going to work for me because it will take forever to chase down the non-compliant users and I have a timeframe to get everything on LDAP.
There is an API that will allow a user to change their account to using SSO at /api/v1/users/switch_to_sso but it was not designed for a system admin to take advantage of, as it requires the user’s password for authentication and also requires the user to sign-in to their GitLab account for verification.
This is on our radar, however, and I have created a Jira ticket here to track a feature that will allow you to force your users to switch to a certain sign-in method.
As for now, if you were to start with a fresh Mattermost instance you could force all users to sign-up with GitLab and you could disable all other sign-up methods from the System Console. Migrating an existing instance programatically would be a bit of a hassle.
Thanks @jwilander. I am sorely tempted to just set everyone’s AuthService / AuthData in the database since it worked fine in the experiment and we didn’t see any issues… so surely in this instance we can just manually make the exact same change that the System Console would do anyway if it supported this?
The alternatives (continue to allow email sign on, or blow away our current instance with all history) are not very appealing.
It’s your database so feel free to massage it to do whatever you like but our policy is to not suggest making manual changes to your Mattermost database, as a simple mistake could cause major issues with your system.
Hi,
Could you share how you did it? Was it via the /users/{user_id}/auth?
I tried to switch the authentication method from email to gitlab, by sending a PUT request to the above endpoint with the following payload:
data = {
'auth_data': '',
'auth_service': 'gitlab',
'password': '12345678'
}
But it didn’t succeed, the error was
{'detailed_error': '',
'id': 'api.context.invalid_body_param.app_error',
'message': 'Invalid or missing user in request body',
'request_id': 'moesc9nrhfbyi8mgky6zsfbpuw',
'status_code': 400}
What would be the proper way to update AuthService, AuthData and Password like you said in your comment?
I edited the database directly, i.e. logged in with a mysql client and ran update on the rows of the Users table. Editing the database this way is not supported and can leave your installation in an inconsistent/broken state, which is why the documentation clearly tells you not to. However, in my case I couldn’t find any other way forward, so I made the change and tested it carefully (backed up first, shut down the server, tried the change, tested out the server with limited user group etc with readiness to roll back if required).
It was some years ago so there may be a supported way to achieve this now, in which case I highly recommend you go with the supported mechanism or any other approach recommended by the mattermost devs, and use database manipulation as a last resort.
