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
)
I have so many questions and thoughts that it will be too long for a comment :
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 ?
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) ?
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.
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.
Related
I am trying to hit this URL https://subdomain.example.com in JMeter and recorded using the Blazemeter Chrome extension has all the necessary config elements but get an error:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html; charset=utf-8
Content-Length: 1031
Connection: keep-alive
Cache-Control: private, no-cache, no-store, must-revalidate
Date: Tue, 20 Aug 2019 01:21:35 GMT
Expires: 0
p3p: CP="This site does not specify a policy in the P3P header"
I have tried coping the Header Cookies from Browser Header Response which works for sometime but then start throwing an error
As per HTTP Status Code 429 Too Many Requests description:
The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").
A Retry-After header might be included to this response indicating how long to wait before making a new request.
So there are following options:
Your server is overloaded, in this case there is nothing you can do here apart from reporting the error as the bottleneck
Your script doesn't have proper correlation implemented, i.e. you're sending recorded hard-coded values instead of getting dynamic parameters
Your server doesn't allow such amount of requests from a single IP address within the given timeframe, you could try implementing IP Spoofing so your server would "think" that the requests are coming from the different machines.
Thanks for your reply. In the end I figured out that no limitation for number of calls implemented.
Now come to answer this is how I managed to work this:
Opened the page in chrome and from the header section copied all the header elements into the header manager hard coded.
First time it fails and returns p3p: CP="This site does not specify a policy in the P3P header" but also return the update variable value needed for next request which I extract and used in the next and subsequent Requests. The way I was able to find out which variable is changing by using the string comparison of 2 Response Headers
This was a difficult one but somehow worked with very minor change I also added the Header Manager to each request for safer side.
I try to write a C++-application and I have to do HTTP Digest Authentication. The problem is not primarily about C++, but about the fact, that the connection is not being established. The website I try to access is the following: httpbin.org/digest-auth/auth/user/passwd .
Consider the following server response to a simple GET /digest-auth/auth/user/passwd:
HTTP/1.1 401 UNAUTHORIZED
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Date: Mon, 08 Sep 2014 15:10:09 GMT
Server: gunicorn/18.0
Set-Cookie: fake=fake_value
Www-Authenticate: Digest realm="me#kennethreitz.com", nonce="2a932bfb1f9a748a7b5ee590d0cf99e0", qop=auth, opaque="2d09668631b42bff8375523e7b27e45e"
Content-Length: 0
Connection: keep-alive
A1 is then computed to be user:me#kennethreitz.com:passwd and is hashed to 4de666b60f91e2444f549243bed5fa4b which I will refer to as HA1.
A2 is computed to be GET:/digest-auth/auth/user/passwd and hashed to b44272ea65ee4af7fb26c5dba58f6863 which I will refer to as HA2.
With this information, the response is computed as HA1:nonce:1:ac3yyj:auth:HA2, where HA1 and HA2 are the values we have just computed and nonce is taken from the server response above, which is in total: 4de666b60f91e2444f549243bed5fa4b:2a932bfb1f9a748a7b5ee590d0cf99e0:1:ac3yyj:auth:b44272ea65ee4af7fb26c5dba58f6863. The hash of that is 55f292e183ead0810528bb2a13b98e00.
Combining all that information should be sufficient to establish a http-connection using digest authentication. However, the following request is declined by the server and answered with another HTTP/1.1 401.
GET /digest-auth/auth/user/passwd HTTP/1.1
Host: httpbin.org
Authorization: Digest username="user", realm="me#kennethreitz.com",nonce="2a932bfb1f9a748a7b5ee590d0cf99e0",uri="/digest-auth/auth/user/passwd",qop=auth,nc=1,cnonce="ac3yyj",response="55f292e183ead0810528bb2a13b98e00",opaque="2d09668631b42bff8375523e7b27e45e"
Note that the formatting does not show the structure of the request. The block from Authorization to opaque is actually one line.
Feel free to re-do the md5-calculation - but I have redone the calculations manually and got the same hashes as my program did. I used that tool (http://md5-hash-online.waraxe.us/) for the manual computations.
Am I missing something obvious here, probably misinterpreting the standard in a way? Why can't I get authorized?
Finally got it. The authentication itself is completely correct.
The server demands a cookie to be set. Apparently one must show that cookie in the reponse, too. That explains why firefox (being a browser) can authenticate correctly while curl and lwp-request can't albeit sticking to the standard - RFC said nothing about cookies. Why do we have standards, that noone cares for?
Anyway, appending Cookie: fake=fake_value to the header solves the problem.
I'm developing a small site w/ Go and I'm trying to set a cookie from my server.
I'm running the server on localhost, with 127.0.0.1 aliased to subdomain-dev.domain.com on port 5080.
My When I receive the response for my POST to subdomain-dev.domain.com:5080/login I can see the set-cookie header. The response looks like this:
HTTP/1.1 307 Temporary Redirect
Location: /
Set-Cookie: myappcookie=encryptedvalue==; Path=/; Expires=Fri, 13 Sep 2013 21:12:12 UTC; Max-Age=900; HttpOnly; Secure
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Date: Fri, 13 Sep 2013 20:57:12 GMT
Why isn't Chrome or Firefox recording this? In Chrome it doesn't show up in the Resources tab. In FF I can't see it either. And in neither do I see it in future Request headers.
See that Secure string in the cookie?
Yeah, me too. But only after a few hours.
Make sure you're accessing your site by SSL (https:// at the beginning of the URL) if you've got the Secure flag set.
If you're developing locally and don't have a cert, make sure you skip that option.
In my case, I had to add this to my response:
access-control-expose-headers: Set-Cookie
I found here that my Set-Cookie header was not accessible to my client unless I added it to the exposed-header header.
Hope this can help someone!
Found related github issue response cookies not being sent that helped.
In my case I am running react app under https (with mkcert tool) and making cross origin fetch request and get response. Cookies of the response is not set until I
specify credentials: 'include' for fetch request
example fetch api
fetch('https://example.com', {
credentials: 'include'
});
Specify these response headers from server
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://localhost:3000
Access-Control-Allow-Origin header has value of the url of my react app.
add these attributes of Set-Cookie Header Path=/; HttpOnly; Secure; SameSite=None using http cookies
Hope it helps someone!
I am trying to find out where a cookie is being set.
I am running Varnish cache and want to know where the cookie is being set so I know if I can safely remove it for caching purposes.
The response headers look like this;
HTTP/1.1 200 OK
Server: Apache/2.2.17 (Ubuntu)
Expires: Mon, 05 Dec 2011 15:11:39 GMT
Cache-Control: no-store, max-age=7200
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
X-Session: NO
X-Cacheable: YES
Date: Tue, 04 Dec 2012 15:29:40 GMT
X-Varnish: 1233768756 1233766580
Age: 1081
Via: 1.1 varnish
Connection: keep-alive
X-Cache: HIT
There is no cookie present. But when loading the same page in a browser the headers are the same, I get a cache hit and no cookie in the response headers.
But then the cookie is there all of a sudden, so it must be being somewhere. Even if I remove it it reappears. It even appears in Incognito mode in Chrome. But it is not in the header response.
I have been through all the javascript on the site and cannot find anything, is there any other way of setting a cookie?
Thanks.
If the Set-Cookie header goes through Varnish at some point, you can use varnishlog to find the request URL:
$ varnishlog -b -m 'RxHeader:Set-Cookie.*COOKIENAME'
This will give you a full varnishlog listing for the backend requests, including the TxURL to the backend which tells you what the client asked for when it got Set-Cookie back.
I am trying to connect through a Bluecoat proxy which uses a cookie during the proxy authentication.
I have been completely unable to find a combination of CURLOPT_ settings that will get CURL to present the cookie during proxy authentication.
So: the proxy responds with:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-EDD688431754D715=2; Path=/
Connection: close
Content-Length: 825
But curl does not present the cookie in subsequent authentication attempts, no matter what I set for CURLOPT_COOKIEFILE or CURLOPT_COOKIEJAR.
NOTE: I am also using (because I must)
CURLOPT_PROXYTYPE = CURLPROXY_HTTP
CURLOPT_PROXYAUTH = CURLAUTH_ANY
CURLOPT_HTTPPROXYTUNNEL = 1
CURLOPT_CONNECT_ONLY = 1
Is it reasonable to expect CURL to present a cookie with a Proxy-Authorization request?
I am using curl_easy_*, would moving to the multi interface help?
Finally, I am building with 7.19.7
The CONNECT request is done a bit separately in the code than the "regular" requests and it seems there's no cookie handling done there! I consider it a libcurl bug.
(This is my comment from above, turned into a proper answer.)
It is possible to create a tunnel through a Blue Coat Proxy. But my advice is not to use a network with the Blue Coat Proxy. In a free country it should not be a problem to buy a SIM card and use a mobile network instead.
Read more at https://bluecoatproxy.wordpress.com