Bug 137745
| Summary: | When in private mode, cookies in iFramed content are not set correctly | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | natenate |
| Component: | Frames | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap, beidson, mhock, sam |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.9 | ||
| URL: | http://run.plnkr.co/my0lgusP2UEYNTbL/ | ||
natenate
I found this in Safari 7.1 and Webkit Nightly:
Steps to repro:
1. Start or restart Webkit
2. Put Webkit into Private Browsing mode
3. Browse to http://run.plnkr.co/my0lgusP2UEYNTbL/
4. Expect the text 'Cookie value is: CSRF-Token=is_this_set%3F' to be visible
5. !! Only see 'Cookie value is: '.
Summary:
The site loads a page, which includes iframed content. The iframed content should have access to a cookie value that is returned by the server (visible in headers) but is not available via Javascript.
Some interesting other observations:
* Sometimes this seems to happen in regular browsing mode, as well as private browsing
* If you right click the iframe, and select "Open Frame in New Tab", the page will load and render the correct value. Bizarrely, if you then go back to http://run.plnkr.co/my0lgusP2UEYNTbL/ and refresh the page, the iframe will load with the correct value!
* If the host is the same in the iframe and the parent frame, the issue is not reproducible: http://safe-everglades-1254.herokuapp.com/iframed
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Martin, sounds like cookie accept policy may be incorrect in private browsing mode?
natenate
It looks like my plnkr.co link died. I'll try to find a permalink.
natenate
http://run.plnkr.co/plunks/b3IFwWieUdiMrjSk3CLW/ should work. Apologies for that.
Alexey Proskuryakov
What is your cookie accept policy in Safari? With the default policy, a cross-origin subframe is not allowed to store cookies.
I suspect that you have a non-default policy set in Safari preferences, and that using private browsing reverts that to default. If so, Safari/WebKit behavior seems incorrect, but I'd like to confirm that this is indeed what you are seeing.
> * If you right click the iframe, and select "Open Frame in New Tab", the page will load and render the correct value. Bizarrely, if you then go back to http://run.plnkr.co/my0lgusP2UEYNTbL/ and refresh the page, the iframe will load with the correct value!
Yes, this is expected for the default cookie policy - cross-origin subframes may not store cookies, but they can read existing ones.
natenate
I never changed my cookie policy. This only happens when I'm browsing in private browsing mode.
Alexey Proskuryakov
So, what is your cookie accept policy?
You say that this only happens in private browsing mode for you, however I can reproduce perfectly well in non-private mode too. Please delete all cookies for safe-everglades-1254.herokuapp.com before re-testing.
natenate
Is there a programmatic way to access the cookie policy, or do you just need to know what my settings are under the privacy tab for cookies? Happy to provide whatever information I can.
Alexey Proskuryakov
> do you just need to know what my settings are under the privacy tab for cookies
Yes, this is what I was asking about.
natenate
Ok, thanks Alexey. You're right, this is also happening when not in Private mode. Here's a screenshot of the settings I have in Safari 8, that also replicates the issue:http://imgur.com/ZJl8vht
Thanks again.
Alexey Proskuryakov
Thank you very much for following up so promptly. Yes, this is the default cookie accept policy, which allows accepting cookies from the main frame, and also from subframes that already have some cookies associated with their domain.
Closing as INVALID, as this is behaving as expected.