You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What steps will reproduce the problem?
1. Login to an account with a sheffield.ac.uk (we use SAML SSO with Google).
2. Get redirected to our internal CAS service (correct)
3. Get logged into our portal (incorrect... this generally happens because the
URL query string is missing that tells CAS to redirect you back to our SAML IdP
before getting passed to Google)
What is the expected output? What do you see instead?
OAuth Token never gets generated as Google never receives a valid SAML response
from our IdP.
What version of the product are you using? On what operating system?
Example application compiled from latest SVN.
Please provide any additional information below.
I've been discussing this problem with the developers of BusyCal. It seems that
gtm-oauth2 is not playing nicely with our IdP. We get to the google sign in
page, which on receipt of a sheffield.ac.uk domain redirects you to our SAML
IdP, which in turn redirects you to our internal CAS servers (our internal
authentication). By this point, the query string seems to have been removed,
which causes our CAS server to log you into the default service (our internal
portal) and the request never gets back to the Google SP.
Original issue reported on code.google.com by a.j.bere...@sheffield.ac.uk on 17 May 2013 at 10:45
The text was updated successfully, but these errors were encountered:
Try setting a breakpoint at requestRedirectedToRequest: in GTMOAuth2SignIn to
identify what's happening.
Can this be resolved by setting a custom redirectURI property in the auth
object?
Original comment by grobb...@google.com on 21 May 2013 at 10:55
After some investigation, I've discovered that this is due to the way GTMOauth2
is overriding cookie handling.
A workaround in the Sample application is to tick the "persist" tickbox which
gets called in addCookiesToRequest. I'm not sure of a fix for it, but there's
definitely something wacky going on in there - possibly in cookiesForURL.
Original comment by a.j.bere...@sheffield.ac.uk on 5 Jul 2013 at 2:50
Original issue reported on code.google.com by
a.j.bere...@sheffield.ac.uk
on 17 May 2013 at 10:45The text was updated successfully, but these errors were encountered: