7

We're experiencing a strange behaviour on MS Edge with at least versions 16/17. The same issue does not happen on IE 11/Chrome/Firefox.

Our users are authenticated via a session cookie. The cookie name is "app". Other cookies involve storing a the current display language with a cookie name of "prefLang". The cookies are HttpOnly, secure and set only for the actual subdomain in use.

In some cases, MS Edge simply drops the session cookie named "app" and is not part of the HTTP request any longer. The mentioned "prefLang" cookie is not dropped and is visible on the server.

The dropping occures is not easily reproducible but has been visible sometimes when:

  • The user opens an externally linked page from the loggedin app context with target=_blank
  • More than 12mins have been passed between page requests within the app context
  • immediately within seconds of page requests
  • the user opens an iframe with a page request from the same origin

Example with request/response debug information server side where the session cookie app=redactedABC is not transmitted to the server

2018-11-28 09:44:00 UTC POST hasIdentity: 1 UserId: <redacted>  Request: https://app.domain.com/page/action/full/add/0 / Cookie: _gid=redacted; _ga=redacted; app=redacted-ABC; prefLang=de

2018-11-28 09:44:00 UTC 200 hasIdentity: 0 UserId: 0  Response headers: Array
(
    [0] => Expires: Thu, 19 Nov 1981 08:52:00 GMT
    [1] => Cache-Control: no-store, no-cache, must-revalidate
    [2] => Pragma: no-cache
)

2018-11-28 09:46:21 UTC POST hasIdentity: 0 UserId: 0  Request: https://app.domain.com/page/action/full/add/0 / Cookie: _gid=redacted; _ga=redacted; prefLang=de

2018-11-28 09:46:21 UTC 302 hasIdentity: 0 UserId: 0  Response headers: Array
(
    [0] => Expires: Thu, 19 Nov 1981 08:52:00 GMT
    [1] => Cache-Control: no-store, no-cache, must-revalidate
    [2] => Pragma: no-cache
    [3] => Set-Cookie: app=redactedXYZ; path=/; domain=app.domain.com; secure; HttpOnly
)

2018-11-28 09:46:21 UTC GET hasIdentity: 0 UserId: 0  Request: https://app.domain.com/account/login / Cookie: _gid=redacted; _ga=redacted; prefLang=de; app=redactedXYZ

2018-11-28 09:46:21 UTC 200 hasIdentity: 0 UserId: 0  Response headers: Array
(
    [0] => Expires: Thu, 19 Nov 1981 08:52:00 GMT
    [1] => Cache-Control: no-store, no-cache, must-revalidate
    [2] => Pragma: no-cache
)
TylerH
  • 20,799
  • 66
  • 75
  • 101
Paul Cream
  • 186
  • 2
  • 14
  • Thanks for informing us about this issue in MS Edge. It can be possible that this issue can only be producible in specific conditions with certain code. So If possible for you than I suggest you to provide any sample code and steps. We will try to make a test with your code to produce the issue. – Deepak-MSFT Nov 30 '18 at 03:17
  • Dear Deepak, The sample code would be to open up external websites with a click. Link>. Nothing else. This was causing the origin tab to lose the session cookie immediately for the next request. Nothing else. But after a few hours, no issue could be observed on the same PC. That was on afresh Win 10 Pro installation, first time usage of Edge, no addons, no extensions, normal mode, version 16.x – Paul Cream Dec 02 '18 at 09:08
  • I can see that issue was solved after few hours as you mentioned in your previous comment. Any Windows related update got installed during those few hours? It is possible that update solved the issue for an Edge browser. I notice that you are using 16.x version of Edge. At present 17.x is the latest version of Edge. so I suggest you to move to the latest version may help you to get latest features of Edge. – Deepak-MSFT Dec 03 '18 at 01:20
  • The issue for one user was solved, I need to check the version of that user. The issue was happening on other users browser using 17.xx too though as mentioned in my original question. Could there have been updates for Edge without bumping the version number? – Paul Cream Dec 03 '18 at 04:34
  • Additionally, the mentioned user where the reproduction failed later that day hat Edge 16.16299 at the time of all testing and it's the same version as of today. – Paul Cream Dec 03 '18 at 08:55
  • MS Edge update comes with Windows updates. So there are no any separate updates available to solve this issue. I tried to make a test with MS Edge 17.17134 but failed to produce the issue. All you can do is update your Windows with latest updates and than try to make a test to check whether it solves your issue or not. – Deepak-MSFT Dec 04 '18 at 07:30
  • As said, we've seen users on 17.17134 affected too. – Paul Cream Dec 04 '18 at 07:46
  • Why does it says cookie expires in 1981? – estinamir Dec 04 '18 at 16:51
  • @Paul, Try to create a sample project that can produce the issue. With that one line of HTML code, We are not able to produce the issue. We need to understand that which exact code you are using to produce the issue. Thanks for your understanding. – Deepak-MSFT Dec 05 '18 at 03:04
  • @bestinamir Thats the HTTP expires header, not the cookie or related to the cookie. – Paul Cream Dec 05 '18 at 10:29
  • @Deepak-MSFTIt's really not 100% reproducible. In some cases, we simply opened an external URL via target="_blank" and then going back with one mouse click to the existing tab, reload the page via HTTP GET request and poof, the session cookie is gone for good. – Paul Cream Dec 05 '18 at 11:04
  • I just experienced this issue on a web site I am developing (on ASP.NET MVC 5). Using the Edge browser I was being sent to the OIDC provider on every request. Coming back to the site, the cookie middleware set the session cookie correctly (with expiration 30 min in the future); I could see it in the cookie list in Edge developer tools. Then I sat constantly refreshing the cookie list to see what was happening with the cookie. After about 10 seconds, the cookie disappeared. All other cookies remained. – Øystein Grande Jaren Mar 14 '19 at 11:35
  • So Edge was actually dropping the asp.net session cookie a few seconds after it was issued. Then upon the next refresh I was of course sent on a round-trip to the identity provider, a new session cookie was set in the browser by the OWIN cookie middleware, and the process repeated itself. This behavior was totally reproducible until i restarted the browser. After restarting Edge, I can no longer reproduce the issue, at least for now. I have never seen anything like this happen in another browser. – Øystein Grande Jaren Mar 14 '19 at 11:48
  • By the way, version info: Microsoft Edge 44.17763.1.0 Microsoft EdgeHTML 18.17763 – Øystein Grande Jaren Mar 14 '19 at 12:00

1 Answers1

2

I have so many questions and thoughts that it will be too long for a comment :

  1. When you say it's ok in other browsers, is it based on some test cases or Edge is only one of the many browsers usually employed ?
  2. Have you managed to check if the cookie is still been registered client side before/after the faulty request ? Have you check the request headers client side ? The question is about Edge forgetting the cookie itself, Edge forgetting to send the cookie, Edge sending a bad cookie. Have you also tried to tweak a bit the cookie name and content (remove domain for instance if feasible in your subdomain context) ?

  3. What about server side ? Load balancers can be an explanation. Session storage could also be a clue (quite low chance though except if the "no returned session cookie" request is the consequence of a previous unlogged invalid cookie kicking). Of course, server side investigations have no sense if others browsers are running flawlessly in a significant number.

  4. How are you running the client side app and performing requests ? Ajax or fetch requests alongside full document loading (your URI's are looking very APIsh) ? Have you noticed a link between request mode and issue ? Unavailability of the cookie data within app client parts can also be a guideline (a service worker that can't access cookies awakening on a request upon seldom met conditions for instance). Edge can also be faulty with cookie sent back with Ajax in local files (an awful app way but I've seen so much weird things).

With informations you've provided, very few of these points seems able to produce such an inconsistent behavior except if mixed in some bloody Edge-sensitive potion. Anyway, the answers may help to focus the issue and define a more reproductible context.

Aside this, I've found a 2-years old thread talking about a very, very, very, similar issue, still active and looking unsolved, for... IE11 (sorry). It's related to session cookie drops when accessed from different browser's processes (like tabs or iframe). I've found nothing about this issue for Edge and I believe that most of the engine have been rewritten, but perhaps you managed to find the haunted section (though you're saying that all is fine on IE11) ?

If you agree, you'd better edit your own question with related relevant points so I can delete this answer that is not a real answer.

Bertrand
  • 1,840
  • 14
  • 22
  • 2
    Great questions! 1. It's based on missing user complaints and deep log file analysis with other user agents besides the Edge ones. 2. I managed to see one request in Edge dev tools to not be in the HTTP request and confirmed that in server side logging. 3. There is no load balancer. The session storage is fine (I in fact checked that by setting the dropped session cookie on my test browser and the session worked just fine) 4. It's both, full document loading and AJAX requests. There are no service workers, and the cookies are HttpOnly flagged. There is no locale storage. – Paul Cream Dec 06 '18 at 09:17
  • It really looks like the cookie dropping only happens after some iframe (again: to the same origin) interaction or opening external URLs in a new tab. I'm aware of the 2y old thread about IE11. IE 11 usage is quite higher and I'll check logs again just to make sure. – Paul Cream Dec 06 '18 at 09:21
  • So, it's obviously client side as you stated. Is the domain used a local one managed by own DNS server or a registerered ? I say that because of the bug with Edge with domain=localhost set in cookie. Are you able to install Whireshark or Fiddler on one of the Edge computer to record all ingoing and outgoing traffic and try to reproduce the issue ? – Bertrand Dec 06 '18 at 13:57
  • The best track I can see is to try to tweak a bit the domain (there's a chance that opening a new tab can mess things a bit with it : https://stackoverflow.com/questions/15075349/dealing-with-two-php-session-cookies) – Bertrand Dec 06 '18 at 13:59
  • Last one try I can think of is to create a regular cookie with a different name that copy the session cookie content and see if it is also dropped when issue occurs. It can be done without messing up users but you have to change things on both sides. The great result would be to know if Edge is allergic to session the cookie by nature or to its content. – Bertrand Dec 06 '18 at 14:06
  • I strongly suspect it's client side, yes :) There is no domain=localhost - this is on our production server, located at app.domain.tld. No, I am not easily able to reproduce the case, what is driving me a bit mad :) – Paul Cream Dec 06 '18 at 14:08
  • I can't fiddle with the cookie domain for security reasons. Additionally, I already have confirmation, that Edge was dropping the rather long session cookie while keeping the rather short prefLang= cookie. This is already visible within the logging snippet from my original question. – Paul Cream Dec 06 '18 at 14:11