OIDC users get deactivated upon server start #1996
Labels
No labels
Abandoned
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
bob the builder
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity#1996
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While setting up a fresh install using exclusively OIDC i noticed that all my users would get deactivated upon restarting the server.
I strongly suspect that this is because the migrations check upon server start deactivates any local accounts which do not have a password set while the OIDC account creation process creates a linked local shadow user that does not have a password.
Quick fix would probably be to check if a value for the given user exists in the
openidsubject_localparttable.OIDC users get deleted upon server startto OIDC users get deactivated upon server startUpdate to version 26.6.2, it includes a fix for this issue.
Yes, I read about OIDC related fixes in the release notes.
However I am already using 26.6.2 and still having this issue.
Adding relevant log snippets
and after restart
@kv318 This migration is only supposed to run once, after which a flag is set that stops it from running again. I can't reproduce the behavior of it running on every server startup on 26.6.2 or on main, so I'm baffled by the fact that it seems to never be setting that flag for you.
If you've been restoring a backup from when you were running 26.6.1, that would be reverting your database to a version without the flag, which makes the migration run again. 26.6.1 doesn't properly set the flag, which is why 26.6.2 was released in the first place.
I am runnig a completely fresh install. No pre-existing database.
But this was a very helpful pointer. If i read it correctly, creating a new server calls fresh() instead of migrate() which means the flag is only set after the first restart but not on initial start.
This seems to be confirmed by the problem not appearing when i create a fresh server -> do a restart and only then start creating users.
Even when working around this e.g. by running just migrate() after fresh() to prevent this migration from running afterwards i think it is worth considering if treating any password-less users as deactivated is intended behavior of the function.
That is the intended behavior of the function, because it's only supposed to run on pre-OIDC databases, and it works perfectly in that case. The only reason it was causing problems is because of a mistake I made in the migration.
Okay, yes, then it does indeed make sense to leave it as is and just make sure fresh installations/databases set the the flag.
Until a fix is live, restarting once after initial setup is a decent enough workaround.