0

It seems keeping all the browsers happy is a challenging task, what with all the security they are adding and the complexities of certificates.

I have a SPA (Vuejs) which is using oidc-client.js to implement OIDC, communicating with an Identity Server (Identity Server 4). First thing to note is that everything works if I run both client and server on localhost.

It is when I deploy the Identity Server to a Staging Server inside our network that things go awry. So, the hostname of the Idp now differs to that of the SPA (which would be normal in production).

After much work, I've got everything working except IE11 (yep IE). I had to do several things to get me there such as:

  • solve the samesite cookie issue of Chrome
  • create self-signed certificates and install the root certificate in the Trusted Certificates
  • add Babel config code and Core.js at the client, to enable IE to not throw errors when promises come into play

So, it's been a long road, yet still, I have to deal with this (see animation): enter image description here

I just can't quite figure out why IE is doing that.
It is not possible to use the dev tools to see any info.
The logs at the server do not contain any information that seems relevant.

Has anyone else seen these "Browser symptoms" in IE.

Happy to provide more information (code, logs etc.) if people think that will help. Just didn't want to dump all that in the initial question, as many people don't like that.

Here are a couple of Fiddler screenshots. The first is from Chrome: enter image description here The second on is for IE11. enter image description here

For some reason, the Silent Refresh is being invoked over and over again with IE11.

I think I can see what is happening, but not sure how to fix it.
There appears to be 2 calls to the Authorize endpoint which fail, conspicuously missing the .AspNetCore.Antiforgery cookie. This results in 2 invocations of silent-refresh.html.

Then, for some reason there is some king of GET request to the base url of the Idp and immediately following on the heels of that request is a request to the Authorize endpoint which does have the .AspNetCore.Antiforgery cookie.

The ship is set straight until the next call to the Authorize endpoint which is the beginning of the next cycle.

However, with Chrome, after the user is logged in, the next call to the Authorize endpoint does contain the cookie.

So, I guess it is the missing cookie which is the issue.

Perhaps this has something to do with the code which I used from this post to solve the Chrome samesite cookie issue?

Cheers

onefootswill
  • 3,707
  • 6
  • 47
  • 101
  • Did you check the [issue list](https://github.com/IdentityServer/IdentityServer4/search?q=IE11&type=Issues) of IdentityServer? Perhaps you can find an answer there. –  Aug 20 '20 at 06:21
  • It seems you are caught in a redirect loop, use Fiddler to capture the traffic to try to identity the problem or post a copy of the failing request /response so taht we can try to help out. – Tore Nestenius Aug 20 '20 at 07:10
  • Hi guys. I have updated the question. I think this might be a cookie issue. But I'm not sure how to fix it. Going to work on this further today. Thanks. – onefootswill Aug 20 '20 at 23:34
  • I think I may have found my solution in this [Github issue](https://github.com/IdentityModel/oidc-client-js/issues/696). I need to use a host other than `localhost`, as there is a zones issue with IE. I will do further testing today, but it seems to be working thus far. I will answer my own question if it proves to be a viable solution. – onefootswill Aug 21 '20 at 01:54

0 Answers0