Report the actual failure reason for attested invitation completion - #124
Merged
Conversation
Meziantou.Analyzer 3.0.190's MA0219 requires a non-empty language attribute on every <c>/<code> XML doc element. All 879 baseline occurrences in this solution are inline <c> spans naming wire/claim tokens, header names, paths, status codes and similar plain values (no <code> blocks exist), so each gets language="text" - the same choice already established for wire-token references. No comment prose, executable code, or any other content changes.
Attested invitation completion collapsed every refusal into the generic invalid-link page and derived the authentication scheme from ClaimsIdentity.AuthenticationType, which carries a protocol artifact rather than the configured cookie scheme. Callers could not tell an unavailable provider address from a mismatched one, and canonical identity failed to resolve for OIDC providers. - Carry a bounded, value-free completion failure reason so a provider callback lands on the page that names its outcome, while every other guard keeps failing closed. - Assert the cookie scheme the completion runs under on both the post-login and provider-callback paths instead of inferring it. - Evaluate email_verified strictly when attestation is configured: only a single claim parsing to exactly true counts as verified. The legacy unsigned exchange keeps forwarding an absent claim as null. - Document which mode applies on the error and well-known pages, and cover the callback paths with real OIDC round-trip specs. Context: #118, #122. Builds on the XML doc language-attribute cleanup in #123, whose commit is the parent of this one.
Resolve js-yaml 4.3.2 within the existing dependency range to address GHSA-2883-xcg3-v3hh. No manifest or dependency-range change is needed.
Attested completion now captures the invited recipient before authentication is awaited, so a configuration reload mid-completion cannot relax the verified-email requirement or switch the recipient being matched. Provider address matching goes through a static, strict verified-address check with no legacy unbound helper on the attested path, backed by a single auth-config snapshot and named failure factories. Duplicate-subject refusals are now logged consistently, and attested completion outcomes (unverified, missing, mismatched email) resolve to their own diagnostic pages instead of collapsing into a generic invalid-link result. Refs #118, #122
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Changed
Fixed