Does not send domain level cookies when origin does not match request url
Reported by
kkeat...@gmail.com,
Aug 21 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: I have two applications with very slightly different hostnames. The first application is (for example) app.foo.bar.domain.net That application serves up a static javascript file (to chrome) that makes a GET request to a second app called... otherapp.bar.domain.net (notice that "foo" is missing.) I have a domain level cookie called MyAuthenticationToken for the ".domain.net" domain. If I connect to either application I can clearly see the cookie being pass in the request headers, however the problem happens when it makes a client side ajax request to otherapp.bar.domain.net. In this case the cookie is NOT passed in the header and I can't authenticate on the server so all my requests are rejected with 401 errors. This feels like a bug because ".domain.net" should indeed be the root domain level cookie for both URLs and it should be included any request from the client going to those urls. I can confirm that Safari does indeed pass the cookie and I don' t have this issue. I have not tried FireFox. What is the expected behavior? Domain level cookie should be sent in this case: Host:otherapp.bar.domain.net Origin:http://app.foo.bar.domain.net Cookie's domain value: ".domain.net" What went wrong? Cookie was not sent Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: n/a OS Version: OS X 10.12.5 Flash Version:
,
Aug 22 2017
[Mac triage] Passing to Network triage queue
,
Aug 22 2017
Can you capture a net-internals trace? https://dev.chromium.org/for-testers/providing-network-details
,
Aug 22 2017
Have you tried setting <foo>.withCredentials = true, where "<foo>" is the name of the XMLHTTPRequest object? No idea if that's the issue, not really my area.
,
Aug 22 2017
Yes, turns out this was a withCredentials = true issue, but the interest thing is this was working when I was using the older domain without having to add the withCredentials header. I guess my question is, should Chrome require that header even if there is a cookie with the root domain? Seems like Safari has different behavior
,
Aug 22 2017
Thank you for providing more feedback. Adding requester "rch@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 23 2017
,
Sep 8 2017
@rch, @mmenke -- friendly ping to look into this issue. Thanks!
,
Sep 8 2017
Sorry, I was just the network triager when the bug came in, but I don't think I have anything to do with this behavior (hence the CORS label). Hopefully mkwst has some idea. (As mmenke said in #4, it's not his area either).
,
Sep 11 2017
Do you have any code you could share with us to help diagnose the problem? If, for example, you're moving from a same-origin to cross-origin request then the behavior makes sense to me (same-origin requests will include credentials by default in cases where cross-origin requests won't).
,
Sep 11 2017
Yes. We want to know whether the XHR destination and the origin page had different origin in the setup referred by "when I was using the older domain" in Comment 5. Please let us know whether there was/is any redirect involved, too.
,
Sep 11 2017
Sorry, I will try to clarify the example
CASE 1: (Cookie passed)
foo.bar.com/path/one (origin)
foo.bar.com/path/two (destination)
CASE 2: (Cookie not passed unless withCredentials: true)
new.bar.com/path/one (origin)
foo.bar.com/path/two (destination)
*cookie is set to ".bar.com" in both cases
I would expect the cookie to be passed w/o needed to flag withCredentials to true in either case.
,
Sep 14 2017
As this is a security issue ,adding 'TE-NeedsTriageHelp' label to remove this issue from TE's Unconfirmed triaging bucket. Could someone from dev team please look into this issue. Thank you!
,
Sep 22 2017
> #12 Case 2 sounds like a cross-origin request. In that case you need to set withCredentials to send credentials, as mkwst@ says.
,
Sep 22 2017
Right. Case 2 is a cross-origin request, which does not include credentials by default. I think this is the behavior we intended to implement. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kkeat...@gmail.com
, Aug 21 2017