This repository was archived by the owner on Oct 28, 2026. It is now read-only.
Repository navigation
Exempt every provider-linked account from enforced TOTP - #34
Merged
Merged
Conversation
The first pass exempted only accounts with no local password, which missed the common case: an account an administrator created with mwdeploy:create-user and then signed into with the provider. Those kept being sent to enrolment, which is exactly what the exemption was meant to stop. The exemption now follows the account — linked to the provider, exempt — rather than whether it happens to have a password. Accounts the provider knows nothing about are unchanged, which is every account on an install without single sign-on. The cost, named in the README, the operations guide and on the settings screen: a linked account that keeps a local password can be entered by that password without the provider seeing it, and so without its MFA. Switching password sign-in off is what closes that, and is the intended configuration for an install relying on the provider for its second factor. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QjX5f2ZtAKYfiQmzWaD8tp
|
Warning Review limit reachedNext included review available in 44 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the commit that missed the #33 merge. It was pushed to the branch after GitHub had already computed that merge, so #33 landed with the email-verification change only and its description promised something the merge did not contain. Rebased onto the merged
mainhere, unchanged.What it fixes
#32 exempted only accounts with no local password, which missed the common case: an account created with
mwdeploy:create-userand later signed into with the provider. Those kept being sent to TOTP enrolment — exactly what the exemption was meant to stop, and the reason this had to be said twice.The exemption now follows the account: linked to the provider (
oidc_subjectis set), exempt. Whether it also has a password no longer matters.Accounts the provider knows nothing about are unchanged, which is every account on an install without single sign-on. Enrolment stays available to everyone, exempt or not.
The cost, stated rather than buried
A linked account that keeps a local password can be entered by that password without the provider seeing it, and so without whatever MFA the provider enforces. Switching password sign-in off (#32) is what closes that, and is the intended configuration for an install relying on the provider for its second factor.
That trade-off is written into the README,
docs/OPERATIONS.mdand the sign-in settings screen itself, so it does not have to be rediscovered from behaviour later.Testing
317 tests pass,
pint --testclean, on the rebased base.an_account_linked_to_the_provider_is_not_forced_to_enrol— the no-password case, as before.a_linked_account_that_kept_its_password_is_exempt_too— the case Make single sign-on able to stand alone, and fix Authentik account linking #32 got wrong. This is the regression guard.a_local_account_with_no_provider_link_must_still_enrol— pins the half that did not change, so a future widening of this rule fails a test rather than quietly removing the requirement from every account.🤖 Generated with Claude Code
https://claude.ai/code/session_01QjX5f2ZtAKYfiQmzWaD8tp
Generated by Claude Code