Repository navigation
Accept only this provider's own confirmation tokens in verify login - #319
Merged
Merged
Conversation
LoginHandler accepted any token with a user::address handshake signed with the service secret, including handshake tokens an application issues for its own purposes, which are not login confirmations. A session token, which has no handshake, caused a nil dereference. The handler now requires a handshake and a provider name matching its own before the replay store is touched, and rejects anything else with 403. Its own confirmation requests have set that name since 2024. The rejected token is redacted from the logged request. Mirrored in v1 and v2. The confirmation fixtures are re-minted with the provider name, as the confirmation request produces them.
Coverage Report for CI Build 38117006047Coverage increased (+0.06%) to 86.72%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
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
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.
Previously,
VerifyHandler.LoginHandleraccepted any token with auser::addresshandshake signed with the service secret, including handshake tokens an application issues for its own purposes, which are not login confirmations. A session token, which has no handshake, caused a nil dereference.After this change, the handler requires a handshake and a provider name matching its own before the replay store is touched, and rejects anything else with 403. Its own confirmation requests have set that name since 2024, so recently issued links keep working. The rejected token is redacted from the logged request. The README notes which tokens the provider accepts.
The change is mirrored in v1 and v2. Regression tests cover rejection, replay-store isolation and log redaction in both modules, and the existing test that sends a real confirmation and signs in with it still passes.