Add experimental and preliminary policy-driven session limiting when logging in OAuth 2 sessions. #5221
Conversation
Deploying matrix-authentication-service-docs with
|
| Latest commit: |
08959fa
|
| Status: | 🚫 Build failed. |
reivilibre
force-pushed
the
rei/policy_driven_session_limit
branch
from
b6ad7a4 to
9f3d978
Compare
reivilibre
force-pushed
the
rei/policy_driven_session_limit
branch
from
9f3d978 to
203bf44
Compare
reivilibre
force-pushed
the
rei/policy_driven_session_limit
branch
from
203bf44 to
071830e
Compare
sandhose
left a comment
sandhose
left a comment
There was a problem hiding this comment.
I'm going to assume TODO after this is mostly dealing with the compat API
| pub soft_limit: u64, | ||
| pub hard_limit: u64, |
There was a problem hiding this comment.
TBD, how does it behave when a limit is set to zero? Would it be worth using NonZeroU64?
crates/policy/src/lib.rs
Outdated
| } | ||
|
|
||
| #[derive(Debug)] | ||
| #[derive(Serialize, Debug)] |
There was a problem hiding this comment.
alternatively this could have a serializeable static part plus rest as two separate properties, which feels a smidge less 'smart', but also fine with this
There was a problem hiding this comment.
ok you tricked me into writing DataBase
|
|
||
| let session_counts = count_user_sessions_for_limiting(&mut repo, &session.user) | ||
| .await | ||
| .map_err(|e| RouteError::Internal(e.into()))?; |
There was a problem hiding this comment.
surprised RouteError doesn't implement From that error?
There was a problem hiding this comment.
oh, anyhow, that's why. Fine then
There was a problem hiding this comment.
to be fair, maybe I should have double-thought it and passed through the database error
Co-authored-by: Copilot <[email protected]>
reivilibre
force-pushed
the
rei/policy_driven_session_limit
branch
from
e0d7fb9 to
08959fa
Compare
Part of: #4339
Intended for commit-by-commit review.
Introduces a soft and hard session limit. At login time, we count the user's existing sessions (OAuth 2, Compat and self-owned Personal) and refuse creation of a new one if the limit is reached. This is configurable by policy.
The soft limit will be used for interactive logins where the user could be shown a web UI to remove devices, whereas the hard limit will be used for
m.login.passwordlogins where the user can't be shown such a UI.Limitations:
These limitations will be handled in future PRs, but for now this is part of the experimental config section.