bigbluebutton
Google omniauth error with successful login
We are getting this message in web browsers after a successful login using Google omniauth.
csrf_detected occured while authenticating with omniauth
From what we can tell, this happens when using Chrome with Sync turned on. It doesn't happen in incognito mode, or when using a non-synchronised profile.
Greenlight v2.6.5 in docker
For support issues, please use https://groups.google.com/forum/#!topic/bigbluebutton-greenlight. Thanks.
Is an error being shown to the user? If not, you can probably just ignore it
Is an error being shown to the user? If not, you can probably just ignore it
Yes, it is. It's discreet, but visible.
I don't know if this bug has been treated up to now, but I see it also in the conditions described here.
Version of Greenlight: 2.7.4
Disclaimer: I tested this using our own OpenID Connect Provider but I highly suspect it's the same cause. Would be great if someone seeing the error could confirm the same (wrong) redirect behaviour when using Google since for some reason I cannot reproduce the error there.
Under some browser circumstances, users get the red banner with said error message. Digging into it, I found the following difference using incognito and not: When logging in without using incognito mode, the redirects are: IdP login -> [greenlight]/auth/openid_connect/callback?code=[code1]&state=[state1] -> [greenlight]/auth/openid_connec/callback?code=[code2]&state=[state2] -> greenlight home screen (logged in but showing error)
Logging in with incognito: IdP login ->[greenlight]/auth/openid_connect/callback?code=[code]&state=[state] -> greenlight home screen (logged in)
The 2nd redirect with the different code and state (which are actually causing the problem) is coming from the return_to cookie which is not set when using incognito. Honestly, I have no idea where it's coming from. I can clear all cookies right before clicking on "Sign in with OpenID Connect" and it'll already be set on the GET to /auth/openid_connect (which then redirects to the IdP).
One solution is to change https://github.com/bigbluebutton/greenlight/blob/3987a8b913efe4498f48bd0cc5811c23f4eef884/app/controllers/concerns/authenticator.rb#L53 so that it removes the query parameters from the return_to cookie before checking if the link is in the dont_redirect_to array. A simple cookies[:return_to].split('?', 2)[0] (see [edit: deleted link]) does the job but doesn't fix the underlying issue: the cookie somewhere somehow being set to the callback URI including some code and state I don't know where they come from. With that simple fix, users at least won't get an error message anymore but the affected ones also won't be redirected to the page they clicked "Sign in" on
(Sorry for deleting it the first time. I just noticed I made another change and wanted to confirm it did not affect my test.)
same here with an own openid IDP Provider: csrf_detected as red banner after successful login.
(openid_connect) Request phase initiated.
(openid_connect) Setup endpoint detected, running now.
(openid_connect) Setup endpoint detected, running now.
(openid_connect) Callback phase initiated.
Support: Auth user ********* is attempting to login.
Support: ********** has successfully logged in.
method=GET path=/b/auth/openid_connect/callback format=html controller=SessionsController action=omniauth status=302 duration=12.19 view=0.00 db=2.98 location=https://greelight.tld
(openid_connect) Setup endpoint detected, running now.
(openid_connect) Callback phase initiated.
(openid_connect) Authentication failure! csrf_detected: OmniAuth::Strategies::OpenIDConnect::CallbackError, csrf_detected | Invalid 'state' parameter
method=GET path=/b/auth/failure format=html controller=SessionsController action=omniauth_fail status=302 duration=5.09 view=0.00 db=0.74 location=https://greenlight.tld ...
i will test the solution from @julianbarskebgw . Thanks for that!
Hi @flyinghuman,
Since you've came across this issue recently I'll refer to you mainly but this is an open request to those who can help answering some of my questions in this context so that I can solve this more efficiently.
The issue is observed when an invalid or unexpected values are caught by the OmniAuth middleware which in turn believes that this is a Cross-Site Request Forgery case and raises the OmniAuth::Strategies::OAuth2::CallbackError with the said error message then it will redirect the request back to /auth/failure with the message as a query parameter when the action omniauth_fail intercept that redirected request and message and redirects the request again to the root_path with a flash alert which will be observed in a red banner which will always be the case once you login with a return_to cookie pointing to the callback URI with invalid parameters.
I'm currently working on a solution (like @julianbarskebgw suggested) but for some reason I found my self unable to reproduce the case naturally (I had to set manually the return_to cookie value just like @julianbarskebgw described so that I can observe the same outcome, BTW thanks a lot Julian for that amazing comment!).
To avoid solving this without finding the root cause that led the return_to cookie in the first place to contain that callback URI and which in turn may raise other problems in the future I'm wondering if you could answer these questions:
- What version of Greenlight are you using (Is it v2.6.5 or v2.7.4 or the latest one?)?
- In the logs you provided @flyinghuman is this redirection location header value complete:
method=GET path=/b/auth/openid_connect/callback format=html controller=SessionsController action=omniauth status=302 duration=12.19 view=0.00 db=2.98 **location=https://greelight.tld**? If not could you provide the full path or at least confirm that it's redirecting you to/b/auth/openid_connect/callbackagain and if so does it use the same authorization code (thecodequery parameter) value or a different one. - Have you observed the error with other providers if so can you tell me which ones?
- Does the error happen rarely or frequently or always? Maybe for some accounts then others?
- Could you provide a clear and a guaranteed (that ensure the same outcome always) scenario to produce the error naturally (without any workarounds like I did)? If providing a clear and a guaranteed scenario isn't possible i.e. in case the scenario itself isn't clear enough can you provide us with the browser logs when the event occurs?
Thanks a lot in advance, Amir,
- What version of Greenlight are you using (Is it v2.6.5 or v2.7.4 or the latest one?)?
the latest one
- In the logs you provided @flyinghuman is this redirection location header value complete:
method=GET path=/b/auth/openid_connect/callback format=html controller=SessionsController action=omniauth status=302 duration=12.19 view=0.00 db=2.98 **location=https://greelight.tld**?
Full Path:
Support: *****@******.tld has successfully logged in.
method=GET path=/b/auth/openid_connect/callback format=html controller=SessionsController action=omniauth status=302 duration=14.19 view=0.00 db=4.51 location=https://************/b/auth/openid_connect/callback host=greenlight
(openid_connect) Setup endpoint detected, running now.
(openid_connect) Callback phase initiated.
(openid_connect) Authentication failure! csrf_detected: OmniAuth::Strategies::OpenIDConnect::CallbackError, csrf_detected | Invalid 'state' parameter
method=GET path=/b/auth/failure format=html controller=SessionsController action=omniauth_fail status=302 duration=10.74 view=0.00 db=1.50 location=https://****************/b/ host=greenlight
If not could you provide the full path or at least confirm that it's redirecting you to
/b/auth/openid_connect/callbackagain and if so does it use the same authorization code (thecodequery parameter) value or a different one.
- Have you observed the error with other providers if so can you tell me which ones? I only tested our own provider; i maybe can check other ones too.
- Does the error happen rarely or frequently or always?
It is Strange. It seems to be cookie related. If i clear my cookies the error is gone. So it is maybe related to older cookies from LDAP Authorization we used before we migrated to OpenID Connect.
Maybe for some accounts then others?
All, but see above because of the cookies.
- Could you provide a clear and a guaranteed (that ensure the same outcome always) scenario to produce the error naturally (without any workarounds like I did)? If providing a clear and a guaranteed scenario isn't possible i.e. in case the scenario itself isn't clear enough can you provide us with the browser logs when the event occurs?
I will test if the issue comes again after clearing the cookies. Actually it seems to be resolved by deleting all related cookies. thanks for your time.
Please note: Greenlight v3 has been released. With this new version, many of the issues and bugs that were present in v2 have been resolved.
As a result, we will no longer be providing updates or support for v2 (except for major security issues), and we will be closing any outstanding bug reports / feature requests related to v2. While we understand that some of you may still be using v2, we highly encourage you to upgrade to v3 to take advantage of the improved features and stability. If your request/bug still applies to v3, please open a new issue for it