Google Oauth fails in rare cases
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.6k
- Forks
- 631
- PR merge metrics
- No merged PRs in 30d
Description
Sometimes gothic.CompleteUserAuth returns error for Google Oauth and I'm not sure what does that mean.
Returned error: could not find a matching session for this request.
I'm using the default session store.
The issue reproduced most often by mobile users.
Successfull login callback:
?state=<omited>
&code=<omited>
&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid
&authuser=1
&prompt=consent
Failing login callback, same user:
?state=<omited>
&code=<omited>
&scope=email+profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+openid
&authuser=0
&prompt=consent
As you can see there is authuser=0 parameter in second case. I wasn't able to find what does that mean. Probably user haven't provided valid credentials on Google Login page. But I can't see why gothic returns error here.
How to handle such errors?
I wonder if this scenario possible:
In browser A, user requests login and enters credentials on Google login page. Upon successful (?) login, a new browser window is created or other browser opened which causes to lose _gothic _session cookie.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the gothic.CompleteUserAuth entry point and trace how the default session store matches the OAuth callback state and session cookie. Compare the successful and failing mobile callback parameters, then reproduce the missing-session case and define what error handling or documentation is expected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100