I have a web app located on domain A which contains an iframe on domain B. The request to the src on domain B has some Set-Cookie headers. If i load this web app with Safari, or chrome, I can see the cookies set from the iframe request in developer tools. However, if i visit the same page on the iOS simulator (iOS 12), the cookies are not set and I get auth errors (due to missing cookies). I haven't had any luck finding anything online about this behaviour so I have no idea how to work around it. I feel like I must be missing something because this seems like it would be a giant missing feature.
Unfortunately, i haven't had time to setup a simple reproduction for this issue.
Any kind of advice would help.
The issue is with Safari iOS do not allow setting cookies from domain B, unless you "explicitly visit" B. Workaround is to visit the iframe domain and set blank cookie there, then bounce back to original A domain. Afterwards your "Set-Cookie" directives or whatever you use to set cookies will be allowed by iOS.
Check out this solution and discussion (also includes reproduction setup):
https://gist.github.com/iansltx/18caf551baaa60b79206
Related
I've just noticed my console is littered with this warning, appearing for every single linked resource. This includes all referenced CSS files, javascript files, SVG images, and even URLs from ajax calls (which respond in JSON). But not images.
The warning, for example in case of a style.css file, will say:
Cookie “PHPSESSID” will be soon treated as cross-site cookie against “http://localhost/style.css” because the scheme does not match.
But, the scheme doesn't match what? The document? Because that it does.
The URL of my site is http://localhost/.
The site and its resources are all on http (no https on localhost)
The domain name is definitely not different because everything is referenced relative to the domain name (meaning the filepaths start with a slash href="/style.css")
The Network inspector just reports a green 200 OK response, showing everything as normal.
It's only Mozilla Firefox that is complaining about this. Chromium seems to not be concerned by anything. I don't have any browser add-ons. The warnings seem to originate from the browser, and each warning links to view the corresponding file source in Debugger.
Why is this appearing?
that was exactly same happening with me. the issue was that, firefox keeps me showing even Cookies of different websites hosted on same URL : "localhost:Port number" stored inside browser memory.
In my case, i have two projects configured to run at http://localhost:62601, when i run first project, it saves that cookie in browser memory. when i run second project having same URL, Cookie is available inside that projects console also.
what you can do, is delete the all of the cookies from browser.
#Paramjot Singh's answer is correct and got me most of the way to where I needed to be. I also wasted a lot of time staring at those warnings.
But to clarify a little, you don't have to delete ALL of your cookies to resolve this. In Firefox, you can delete individual site cookies, which will keep your settings on other sites.
To do so, click the hamburger menu in the top right, then, Options->Privacy & Security or Settings->Privacy & Security
From here, scroll down about half-way and find Cookies and Site Data. Don't click Clear Data. Instead, click Manage Data. Then, search for the site you are having the notices on, highlight it, and Remove Selected
Simple, I know, but I made the mistake of clearing everything the first time - maybe this will prevent someone from doing same.
The warning is given because, according to MDN web docs:
Standards related to the Cookie SameSite attribute recently changed such that:
The cookie-sending behaviour if SameSite is not specified is SameSite=Lax. Previously the default was that cookies were sent for all requests.
Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
Which indicates that a secure context/HTTPS is required in order to allow cross site cookies by setting SameSite=None Secure for the cookie.
According to Mozilla, you should explicitly communicate the intended SameSite policy for your cookie (rather than relying on browsers to apply SameSite=Lax automatically), otherwise you might get a warning like this:
Cookie “myCookie” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute.
The suggestion to simply delete localhost cookies is not actually solving the problem. The solution is to properly set the SameSite attribute of cookies being set by the server and use HTTPS if needed.
Firefox is not the only browser making these changes. Apparently the version of Chrome I am using (84.0.4147.125) has already implemented the changes as I got this message in the console:
The previously mentioned MDN article and this article by Mike Conca have great information about changes to SameSite cookie behavior.
Guess you are using WAMP or LAMP etc. The first thing you need to do is enable ssl on WAMP as you will find many references saying you need to adjust the cookie settings to SameSite=None; Secure That entails your local connection being secure. There are instructions on this link https://articlebin.michaelmilette.com/how-to-add-ssl-https-to-wampserver/ as well as some YouTube vids.
The important thing to note is that when creating the SSL certificate you should use sha256 encoding as sha1 is now deprecated and will throw another warning.
There is a good explanation of SameSite cookies on https://web.dev/samesite-cookies-explained/
I was struggling with the same issue and solved it by making sure the Apache 2.4 headers module was enabled and than added one line of code
Header always edit Set-Cookie ^(.")$ $1;HttpOnly;Secure
I wasted lots of time staring at the same sets of warnings in the Inspector until it dawned on me that the cookies were persisting and needed purging.
Apparently Chrome was going to introduce the new rules by now but Covid-19 meant a lot of websites might have been broken while people worked from home. The major browsers are working together on the SameSite attribute this so it will be in force soon.
I have jupyterhub(TLJH) running on my AWS. It is served on my site using an iframe. Since the latest chrome update, the "SameSite" cookie attribute is causing the following issue. The below image shows what I see in the Iframe
Given below is the warning I get in my console:
A cookie associated with a cross-site resource at http://www._____.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
When I disable the SameSite attribute in chrome://flags/, the iframe loads perfect.
I understand that I need to edit my cookie settings to add {SameSite=None; Secure} somewhere in jupyterhub, but I don't know where.
It looks to me as if you may be able to use the cookie_options setting to add SameSite=None; Secure to the cookies, but I am not 100% sure.
I've raised https://github.com/jupyterhub/jupyterhub/issues/3117 to ask the team to validate.
I could make it work only by making my server map to a subdomain. For example, say the main website which has the Iframe embed is www.mydomain.com, I had to map my Jupyter server to "subdomain.mydomain.com" to make it work.
It is obvious that the above approach was possible because the page I was trying to embed was owned by me. Hoping for an answer for the other scenario!
You can use jupyterhub proxy give your server a domain name like "http:***.mydomain.com" .But this must be subdomain of your site("http://www._____.com/")
I have mysite.com and mysite.nl.
I want to build single sign-on, someone signing in on .com should be signed in in .nl.
I do this by putting an image (1 pixel transparent PNG image) on the .nl domain which sends back a cookie in the response.
In my firefox dev tools, I see 'response cookie' and it's set. It looks like this:
I have made sure the domain is set to mysite.nl
But somehow, when I then navigate to mysite.nl I don't see the cookie set. Am I missing something? I tried disabling tracker blocking, but to no avail.
Google is doing it this way as well right? Ie., log in in Google and you're logged in in Youtube.
If the browser makes a request to xyz.mysite.com, it has to drop the domain cookie for mysite.nl. This is due to the browser security model. If you want to achieve Single Sign On between xyz.mysite.com and xyz.mysite.nl you need some technology to 'transfer' the session token between the two domains. Either you use a standards-backed technology like SAML or OIDC or you use a proprietary mechanism. If you carefully look at the HTTP response, you will see two Set-Cookie HTTP response headers, one has domain property set to mysite.com, one has set domain property to mysite.nl.
UPDATE 2:
I found the reason, but not a solution yet. This has to do with how safari browsers deal with the '#' when Cloudfront redirects HTTP to HTTPS. Safari ignores the hashtag, and apparently this is a bug that's existed in Safari for years. I'm not 100% sure this is my issue, but it seems to be. Still looking for a solution.
END UPDATE 2
For some reason I'm having trouble figuring out, Safari browsers (mobile and desktop) act differently from Chrome and Firefox when I refresh a page or try to access a route directly on my app.
I have a playlists route:
Router.map(function() {
...
this.resource("playlists", function () {});
...
});
I can hit the playlists route directly with rooturl.com/playlists on Chrome and Firefox and in the console logs, I see this:
Attempting URL transition to /playlists
When I try to hit the playlists route directly in Safari, I see this:
Attempting URL transition to /
Another strange thing is that when I use my localhost the transition is correct on all browsers including safari (mobile and desktop). This makes me think it has something to do with the production environment. I'm using AWS S3 and Cloudfront, but I'm not fully sure that has anything to do with this.
I can provide more information here if asked.
UPDATE:
When I use the fragment (followed by a '#') in the url, safari redirects correctly. So this redirects correctly:
example.com/#/playlists
But this does not:
example.com/playlists
Again, this problem only occurs in production, on AWS S3/Cloudfront. On localhost, Safari works as expected.
In my case, this was fixed by making sure the protocol is not switched from https to http at any point. Specifically, S3 was issuing a redirect over http while the original request was over https. This leads to Safari stripping the request from any (potentially) sensitive data.
Fixed it by adding https to our S3 redirect setup.
I am having a problem viewing a cookie value in Safari 6 developer tools. Just to be clear - the cookie works fine. I can see/fetch/echo the value of the cookie on the page. However, I can't see it in the Storage section of Web Inspector.
I'm wondering if the problem is multi-level subdomains. We have these:
www.domain.com
sub.domain.com
www.dev.int.domain.com (accessible only while on VPN)
We want this cookie accessible to all the domains, so we set a domain-level cookie like so (example):
Set-Cookie: UserLoginCookie=someencryptedvalue; Domain=.domain.com; Expires=Sun, 23-Mar-2014 00:02:56; Max-Age=31104000; Path=/; Version=1; HttpOnly
I'm looking in Web Inspector, in the Storage section, under Cookies.
When I load www.domain.com, I see the UserLoginCookie in the list.
When I load sub.domain.com, I see the UserLoginCookie in the list.
When I load www.dev.int.domain.com, I do NOT see the cookie, even though I can read/set it.
I've tried to google for this and search stackoverflow, but I've gotten nowhere. Does anyone know if this is a Safari bug or if there's just a step/option that I'm missing somewhere?
Thanks in advance for any help.
I am guessing this is a Webkit based bug that Safari has yet to fix - Webkit Developer Tools does not show parent domain cookies?
There is no easy way to do it as Safari removed the ability to see individual cookies from the Security tab: "Show Cookies" button missing as per this HOWTO. I have also tried the "Safari Cookies" plugin but it does not work as the cookie list did not refresh for me.
I've resolved to inspecting cookies with the 'document.cookie' in the developer console.