I'm trying to use the XAuth cross domain cookie trick with iOS 7. It does not seem to work.
When I mention cookies below it's really both cookies and localStorage values being set.
I have a page on www.client1.com opening a static webpage in an iframe on www.server.com that sets a cookie with a unique id. Next I open a new window/tab that loads www.client2.com that opens an iframe to www.server.com and attempt to access that same unique id from the cookie previously set.
This works on all platforms, including previous versions of iOS, that I have tried. But not on iOS 7.
I'm using the postMessage method to send information between the iframe and main frame.
What have they changed in iOS 7? Is there any way around this?
I was having a similar problem with a child iframe on b.com with an app cache manifest, hosted in a page served from a.com. The cache manifest would never be fetched by Safari so the child app would never be cached. Happened in WebViews also.
It turns out that iOS7 has a new Privacy/Security setting for blocking cookies (in previous versions of iOS the setting was for accepting cookies), and I found it must be set to 'Never'. The default is to block cookies 'From third parties and advertisers', and that is why my cache manifest was being blocked, and why your cookies aren't being retained.
I have a specialized audience so I can direct users to change their settings. I suppose without this luxury you would have to resort to redirection-fu to flip between the domains and back to ensure that the proper cookies get dropped. However, that approach still may not let child iframes see their own cookies -- Safari may block (i.e., not send) those cookies when the iframe is hosted in a page from a different domain. I haven't tested to confirm this, however.
FYI...
I am a Product Manager who's app had an issue with the cookie updates made in iOS7.0
- We use cookies to support user authentication....and the new cookie policy applied to both Safari AND apps.
This issue appears to have been addressed in iOS 7.0.3
Related
I have a client website that is managed by client team and post clicking on login it comes to the site which is managed by us. Till now, we were extracting the referer URL from the request header and using it to take further actions, but currently due to some changes in the Chrome browser and Edge browser policy we are unable to get the complete referer URL. It works fine in Firefox and Internet Explorer. This is probably because of the browser policy which is restricting the complete referer URL to be send when sec-fetch-site is cross-site. Please help me with some easy code level ways (Java/JSP/Javascript) to extract the complete URL. I tried exploring few links but none helped me resolving this.
Mozilla Firefox and Internet Explorer use a referrer policy called ‘no-referrer-when-downgrade’. Earlier Chrome also used the same policy but it has now shifted to ‘strict-origin-when-cross-origin’ which restricts the referrer URL to only include the domain of the URL.
The resolution to make it work it for Chrome browser as well is to set the policy to ‘no-referrer-when-downgrade’ in the page where your request begins from i.e. the initial page (which in your case is the client managed one), which will help send the complete details and the browser’s default policy won’t be applied. You may refer to below link for better understanding of these changed policies:
https://www.w3.org/TR/referrer-policy/
We are working on two web applications that are hosted on two different subdomains of the same domain:
https://subDomainA.domain.com
https://subDomainB.domain.com
Both web applications are showing an iFrame hosted on a third subdomain:
https://subDomainC.domain.com
We are using postMessage to communicate between top window and IFrame window.
Within the iFrame shown on subDomainA, we are setting an AuthToken:
localStorage.setItem("AuthToken", "JWTAuthToken")
When we navigate to subDomainB and try to run the following code within the iFrame:
localStorage.getItem("AuthToken")
The result is null.
This only happens in the Safari browser.
All other browsers share the LocalStorage within these IFrames
We are on the same domain, i.e. the same "eTLD+1" (domain.com)
Doing the exact same thing with cookies works!. Just not with LocalStorage
Opening subDomainC directly in the browser and setting the data persists them for the IFrames as well.
Is this a indended behaviour of Safari or do we have an issue with our implementation?
This is the expected behavior in Safari. Safari's Intelligent Tracking Prevention (ITP) partitions browser storage based on the top frame. Here's how WebKit's documentation explains it:
Partitioning is a technology to allow third-parties to use storage and stateful web features, but have those isolated per first-party website. Let’s say adtech.example is a third-party under both news.example and blog.example and that adtech.example uses LocalStorage. With partitioned LocalStorage, adtech.example will get unique storage instances under news.example and blog.example which removes the possibility to do cross-site tracking through LocalStorage.
References:
https://webkit.org/tracking-prevention/#partitioned-third-party-localstorage
Iframe localStorage on Safari and Safari mobile
In slightly plainer English, https://github.com/zendesk/cross-storage says :
Notes on Safari 7+ (OSX, iOS)
All cross-domain local storage access is disabled by default with Safari 7+. This is a result of the "Block cookies and other website data" privacy setting being set to "From third parties and advertisers". Any cross-storage client code will not crash, however, it will only have access to a sandboxed, isolated local storage instance. As such, none of the data previously set by other origins will be accessible. If an option, one could fall back to using root cookies for those user agents, or requesting the data from a server-side store.
This may be of use:
https://webkit.org/blog/8124/introducing-storage-access-api/
According to the same-origin policy, different subdomains are considered cross-origin.
You should use postMessage for cross-origin communication.
It seems that the recent updates to the Safari browser (Prevent cross-site tracking) blocks any cookies from being generated when the Matomo domain doesn't match the website it's being loaded from.
This breaks the use of iFrames for Matomo that require cookies to be set (For example the logme feature)
There doesn't seem to be any way to fix this with headers (Eg using CSP or CORS configurations).
current workarounds exist that I've found:
Disable the "Prevent cross-site tracking" setting in the Privacy settings
Redirect the visitor to the page outside of an iFrame to set the cookie - after this the iFrame can load as long as the CORS configuration is correct and the browser isn't completely blocking the iFrame from loading.
I'm not sure how many users are using iFrames that would require cookies to be set, but they would be impacted if any of their users use Safari.
I'm using a Chrome extension to help me work on a webpage but it's setting cookies from doubleclick.net even though I've disabled third party cookies in the Chrome settings. It's annoying because they're filling up my console with messages.
They're not appearing in document.cookie so is there any way to delete them in JavaScript? Or some other way to stop them being set?
I personally the use EditThisCookie extension for chrome when developing web apps using cookies. It allows creation, editing, deleting and most importantly for you blocking of cookies.
You can block a domain from setting a cookie by:
1. Select the cookie from the menu and click block.
2. This opens a menu where you can set a rule blocking the domain from creating new cookies.
Summary: A client has a problem when launching a new browser window using IE11, where no cookies are sent to the new window. I am unable to reproduce the problem locally. It will work if they use FireFox or a different LMS.
Detail: The client is running a LMS and imports a SCORM package from us which opens a frameset to our site - note the clients LMS and our content are on different domains.
As part of the content the user clicks on a link and a new window is opened using window.open(url, "_blank"...) or an anchor tag with a _blank target, the url is always on the same domain as the page that launched it.
When the new window is opened no cookies from the previous page are sent.
I can see that additional requests on the previous page maintain the cookies and new cookies set within the new window are sent back and forth.
If the client uses FireFox to launch the LMS or if the client launches the content from ScormCloud within IE the problem does not occur and the new window launches with all cookies intact.
I have attempted to replicate their environment locally (same OS, IE and configuration settings) but I am unable to reproduce the problem, or work out how to work around the problem.
Any ideas on what the problem may be, how to reproduce it or even work around it?
We have a web app that runs in Facebook (i.e. a running in an iFrame at a different domain). If a Safari user has Cookies and Website Data set to the default, "Allow from websites I visit", the data we store via localStorage.setItem is acting like sessionStorage, i.e. it's not available beyond the user's current session (i.e. after the user closes the tab). If we change the setting to "Always allow", it works fine just like in Chrome, IE , etc.
As a test, we've tried navigating the browser to our app's domain (https://ourappname.appspot.com) directly and it works fine there. And also then it should truly be a visited website, but when going back to the game within Facebook, the problem still exists.
Note that the setItem call is succeeding, it's just that getItem doesn't return anything in a subsequent session. (So it's not like when the user is Private Browsing and the setItem call itself fails with a Quota Exceeded error.)
What do we need to do to support Safari so that our app, running within Facebook, can use localStorage as intended where the data will survive between sessions?
It's either a bug in Safari or a security feature.
You are visiting FaceBook and not your website. Your app is in iframe which would violate security model if it let you read any data from the browser. Think if a competitor site read data it did/didn't set. That'd constitute an information leak.
Safari is doing it's job well in that regard.
Ideally, in "Allow from websites I visit" mode, no browser should let iframes to set data to localStorage; even if every domain has their own storage-sandboxes.
What's troubling me is why are they even letting you write to localStorage from iframe at all (in your 'Allow for only sites I visit' mode)? That might actually be a bug - a information spoof attack enabling bug.
I think it's because security-exceptions were dropped from localStorage in case of not-same-party origin of request. So Safari might actually will not throw error but let it silently fail (in some cases). That's probably why your setItem call is succeeding.
At this point, with the given information, I suspect, sir you are out of luck due to Safari programmers following standard to the letter.
I'm still waiting on a reply from Apple, but it's safe to say we're stuck with this behavior. So Anubhav's answer is accurate, but we still needed a solution.
So as a work around, we created new endpoints on our server for persisting/restoring game state. We only utilize this for Safari, for all other browsers we're still persisting our game state in localStorage.
There is a slight performance penalty for the user. And a slight server cost. Not a sexy solution, but now our Facebook canvas app supports Safari.