At my work, we are finally upgrading our old Identity Server 3 to 4. We just got a very weird problem doing so. Everything works fine in all major browsers, but we also need to support some Electron clients. Here is where the weird part begins. All very old clients using Electron version 3 still work. All newer clients starting at Electron 9 also work. The only clients that don't work are the ones using Electron 6 (Chrome 76).
I already found this very helpful article written by Sebastian Gingter which helped to get the login working. But it only got me one step further. Now the client gets stuck at the connect/authorize/callback endpoint using the response_mode = form_post.
I already found some articles/stackoverflow questions pointing out to check the redirect URIs and to downgrade the CSP to version 1. The redirect URIs are configured correctly since the other clients work. The CSP does not help since I don't even get that far. It seems that the response body is never even loaded by Electron/Chrome.
Devtools Timing Screenshot
The request never finishes. On the server-side, it does though. I debugged through the IS 4 code and the dynamic HTML is written to the response like with all the other clients. I even called CompleteAsync() on the response manually and it still did not finish.
I researched and debugged for quite some time now and am out of ideas. Does anyone out there know this issue and more importantly also knows how to fix it?
Related
Since Friday all of our users are seeing sporadic 302s when trying to access our in-GCP IAP protected resources. Cookies are valid, and definitely being passed with the request.
This has worked for us for two years and nothing has changed here recently past standard GKE upgrades.
Since Friday we're seeing sporadic 302s from IAP (X-Goog-IAP-Generated-Response: true) as if the cookie is invalid. I can recreate this problem using a simple curl command, with my cookie stored in a file called cookie.test.
`curl -vs -b ./cookie.test https://gitlab.mydomain.com/projects/myapp.git
This succeeds maybe 1 out of 5 times. Behaviour is very recreatable. 2 out of 5 times we'll get a response from gitlab.mydomain.com and the other 3 times we'll see a 303 to accounts.google.com. Same cookie every time, all requests within a few seconds of each other.
This is causing an enormous inconvenience for our team.
Has there been a change to IAP recently that might explain this? Do you have any other reports of similar behaviour?
Folks,
I am from the IAP team at Google. Recently IAP has made some changes to the cookie name. However, this change should have been transparent to the browser users.
For people using GCP_IAAP_AUTH_TOKEN cookie name for programmatic auth, your flows will break. The documented way to send credentials in a programmatic call is to use Authorization / Proxy-Authorization header.
https://cloud.google.com/iap/docs/authentication-howto#authenticating_a_user_account
Cookies are meant to be used for browser flows only and IAP holds complete control of the naming and format of the cookie. If you continue to use cookies to send in credentials to IAP (by reverse engineering the new format), you run a risk of being broken again by future changes in cookie name/format.
One clarification is required though. In the original post, it was mentioned that you are getting a response of 302 to accounts.google.com, is that true for browser flows also? If so, please respond back with a har file and I'll be happy to take a look.
cheers.
I have also started facing this issue since last week and have spent around 2 days troubleshooting it as initially we thought that it must be some problem on our side.
Good to know that I am not the only one facing it.
Would really appreciate some updates from Google Around it.
However, one thing I found:- There was one official blog from google around IAP:- https://cloud.google.com/blog/products/identity-security/getting-started-with-cloud-identity-aware-proxy
they have updated this blog on 19th January and removed the mention of the cookie:- GCP_IAAP_AUTH_TOKEN
However, the line they have changed is still unclear to me and very confusing
It now says :-
That token can come from either a browser cookie or, for programmatic
access, from an Authorization: bearer header.
From where will the browser cookie come, what will be its name, there is no mention around it.
Let me know if someone finds a way to get it work again.
Thanks,
Nishant Shah
We are using Cloudflare on one of our sites and last week we have noticed that the site dosen`t load properly. We can see the following error in the console:
A Parser-blocking, cross-origin script,
http://ajax.cloudflare.com/cdn-cgi/nexp/dok3v=f2befc48d1/cloudflare.min.js,
is invoked via document.write. This may be blocked by the browser if
the device has poor network connectivity. See
https://www.chromestatus.com/feature/5718547946799104 for more
details.
This happens in Firefox and Chrome, since last week as new versions of these browsers came out. We have tried to contact Cloudflare, however there is no reply from them. Inspecting their code we can see the document.write and we haven`t got access to this.
Anyone came across with any solution on this?
We currently have a set up with a load balancer carrying out SSL offloading, an http server and a websphere app server. Having got over the initial hurdle of the offloading preventing CAS from thinking it was running under https (which we got around by using the httpsIndicatorHeader variable), we now have another issue. Despite the fact we can see CAS redirecting to the target application, the 'handshake' seems to fail, showing a loop of tickets being generated and tried, but never actually validating, and the target application is never reached. There do not seem to be any errors being generated however.
Has anyone experienced anything similar before?
Cheers,
Rob
After investigation, the problem was that the application redirect url set up in websphere was pointing to the original url, rather than suffixing /j_spring_cas_security_check. This caused the circular loop to occur without any attempt to validate the ticket.
We have recently moved our webserver to a new machine (IIS based) and in the asp.net mvc application I am working on, I have noticed that in the firebug console each request fails twice with a 401 error before finally succeeding on the 3rd try. This did not happen previously and the application seems to be running slightly slower than before, though that could just be my perception.
What might be causing this issue and what might I be able to do in order to avoid it?
I ran into a similar problem couple weeks back and the below post saved my day...
https://serverfault.com/questions/137073/401-unauthorized-on-server-2008-r2-iis-7-5
I hope this may help you...
Consider trying to check your IIS pool. Or maybe a timeout expiration?
This is an issue sporadically for very few users, however we haven't been able to replicate it. However I have now got a Chrome instance (Mac) which is reproducing the error (for some unknown reason), and I hope to not restart it until I have this nailed!
Rails application, using memcached for session store. While the bug manifests in the _app_session_id cookie not being created, our javascript-generated cookie test and app-generated language cookies are being created successfully. This means that InvalidAuthenticityToken errors are thrown for every form that is submitted by those afflicted - people can't log into the app.
The error occurs across all browsers - had reports for IE7 and Firefox (which most users use). Switching to another browser often fixes the issue (though not always), and standard cache-cookie-clear tactics do not.
So now that I have got Chrome open which is having the same issue - in development, staging and live environments (meaning http and https). All other browsers are fine.
I've restarted the servers and restarted memcached. I don't really want to restart Chrome - in the risk that the issue does go away with that (having said that, it hasn't worked for users).
I've been tcpdumping the requests - and although I'll keep digging, I'd love it if anyone had any suggestions, places to start looking, anything. This is really painful ;)
Thanks!