Repository navigation
Fix PKCE auth_session duplicate key error (SQLSTATE 23505) - #6
Merged
Merged
Conversation
After CreateAuthorizeCodeSession, CreatePKCERequestSession was trying to INSERT a new row with the same access_token, violating the UNIQUE constraint idx_auth_session_uniq_access_token_id. Fixed by updating the existing row instead of inserting a duplicate: - CreatePKCERequestSession now looks up the existing session by access_token - Merges PKCE data (code_challenge, code_challenge_method) into the form - Updates the existing row instead of INSERT - Only INSERTs if no row exists (edge case) Updated test to use the same code signature for both calls, matching production behavior and verifying the UPDATE logic. Co-authored-by: Dmitry <demdxx@gmail.com>
demdxx
added a commit
that referenced
this pull request
Sep 18, 2026
During authorization_code grant flow, CreateAccessTokenSession was INSERTing a new row with the same request_id from the authorize step, violating the UNIQUE constraint idx_auth_session_uniq_request_id. Root cause: Fosite reuses the same request.GetID() across the authorize and token exchange steps, so both CreateAuthorizeCodeSession and CreateAccessTokenSession were trying to create separate rows with the same request_id. Fix: CreateAccessTokenSession now: 1. Looks up the existing session by request_id (from authorize step) 2. Updates it with the new access token signature and session data 3. Only INSERTs if no existing session is found (edge case) This matches the approach used in CreatePKCERequestSession (PR #6) and aligns with how fosite manages OAuth sessions - a single session row evolves through the authorize → token exchange lifecycle. Added TestAuthorizationCodeToAccessTokenFlow to verify the full flow: CreateAuthorizeCodeSession → CreateAccessTokenSession correctly updates the existing session instead of creating a duplicate.
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.
Problem
After
CreateAuthorizeCodeSession,CreatePKCERequestSessionwas attempting to INSERT a new row using the sameAuthorizeCodeSignatureas theaccess_token, causing a unique constraint violation:This bug was confirmed in Affyard production. Fosite calls both methods with the same code signature, but the previous implementation tried to INSERT twice, violating the
UNIQUE(access_token)constraint.Solution
Modified
CreatePKCERequestSessionto UPDATE the existing authorize code session instead of INSERTing a duplicate:access_token(the authorize code signature)code_challenge,code_challenge_method) into the existing form dataChanges
CreatePKCERequestSessionto use UPDATE instead of INSERTTesting
✅ All existing tests pass
✅ New test validates UPDATE behavior with same code signature
✅
OAuth2PKCEFactoryconfirmed in correct position (afterOAuth2AuthorizeExplicitFactory)✅ All tests pass locally:
go test ./... -v→ PASSCI Status
go.modrequires Go 1.26.0.github/workflows/tests.ymluses Go 1.25.xSee main branch recent runs: all failing with same version mismatch issue.
Notes
UNIQUE(access_token)constraint intact