Potential bug in forum SSO login
We have a new user who can't log in via SSO.
This is the error he's getting. Any ideas as to how/why this may happen?
- CChristian Scheuer @chrscheuer
The user in question has SSO ID fyZ0OZsxOPdHEMvtaz7vwkCkv112
- In reply tochrscheuer⬆:KajMagnus @KajMagnus2019-11-25 14:31:55.959Z
Here's the code: ( app/controllers/ApiV0Controller.scala )
val oneTimeSecret = getOnlyOrThrow("oneTimeSecret", "TyE7AKK25") val anyUserId = dao.redisCache.getOneTimeLoginUserIdDestroySecret(oneTimeSecret) val userId = anyUserId getOrElse { throwForbidden("TyELGISECR_", "Non-existing or expired or already used one time secret") }
So this happens, if the login secret is incorrect, or it doesn't get used within 10 minutes (expire time), or if it gets used more than once.
Could there possibly be a double-redirect somehow, or accidental page reload, resulting in the same one-time-secret getting reused?
- CChristian Scheuer @chrscheuer
Hmm.. yea accidental page reload maybe.. The user is a new user so it's gonna take some time to get the information from him. Have never heard about this error before.
if the login secret is incorrect, or it doesn't get used within 10 minutes (expire time), or if it gets used more than once.
For debugging purposes would it be possible to make this error message specify which of these conditions it is? Depending on the situation, the debugging would be very different for each case...
- KajMagnus @KajMagnus2019-11-25 20:13:08.418Z
For debugging purposes would it be possible to make this error message specify which of these conditions it is?
That sounds like a good idea yes. I'll look into this. I hope I can release a new version in two days, with the upsert-pages API and this SSO troubleshooting thing.
(Thoughts about security: If someone actually has a real one-time-secret, then s/he knows already that it's a real secret for sure. Because they're impossible to generate oneself. So, not telling the person if the secret is, or was once, valid or not — that's pointless (right?). Since s/he knows already. )
- CChristian Scheuer @chrscheuer
I'll look into this. I hope I can release a new version in two days, with the upsert-pages API and this SSO troubleshooting thing.
Wonderful!
If someone actually has a real one-time-secret, then s/he knows already that it's a real secret for sure. Because they're impossible to generate oneself. So, not telling the person if the secret is, or was once, valid or not — that's pointless (right?). Since s/he knows already
Not sure I follow your thoughts completely but no I don't think there will be security ramifications by giving precise error messages here.
To me the point is:- if the secret is incorrect, then that indicates something is wrong in our code or formatting or error handling internally
- if the secret expired that indicates one case of a user not following through with a request (maybe the redirect got stopped half way)
- if the secret was already used once that indicates a redirect loop.
I have zero idea why the user would experience this, but he's having trouble connecting to the SoundFlow app service itself as well and from looking at our logs they could indicate that he has a particularly flaky internet connection.
- CChristian Scheuer @chrscheuer
By the way - the pages upsert API is much more important to us than the SSO thing. It's just one single customer and he found a workaround.
So if you have a chance of releasing the pages upsert and the login secret change makes the update too bulky, we'd definitely prefer just the pages upsert :) Just in case I wasn't clear on our priorities :)