iOS11: Cookies intermittently blocked

Correct myself. The cookie is present in the request but its values are not

In my experience, this kind of issues is often caused by starting your website in an iframe.

No iframes are involved

We are having similiar issues with our web app since upgrading to iOS 11 and we are not using iFrames either. At times the cookie will not be present in the request to the login service thus forcing the user to login. Other times it will be present when it shouldn't be (after expiring it from the logout service).

When logging in we add a persistent authentication cookie. When you log out, close the app then relaunch it will sometimes log you right back in to the application because it isn't removing the expired cookie and can be seen in the request back to the login service when launching the application.

Other times it is like you described where you login, close the app without logging out. Then launch the application again from the home screen. The persistent cookie is not present in the request at all thus forcing the user to login again.

It is hard to troubleshoot also because for some reason the device wont appear any more in the Safari Web Inspector on Mac when trying to debug it. Just says 'No Inspectable Applications'

We created a very simple web app that just logs in and out to demonstrate and is also linked to this stackoverflow post:

https://stackoverflow.com/questions/46551996/ios-11-cookie-expiration-in-home-screen-web-apps

Sounds like the exact same problem we are having.

What happens if you wait ~10 minutes before you start the web app again after a failed start up? Our web app seems to heal over time. When waiting a couple of minutes after a startup failed (ie cookies were missing in request) before starting the web app again the login request works fine again.

It's realy annoying not being able to inspect the client when running it in standalone mode!

I am seeing the exact same issues. Webapps are serverly broken in iOS 11. Also caching is completely nuts here.

We were also having similar issue but found workaround for it.

In iOS 11, cookies are not shared between Safari and each web apps, but it seems a web app sometimes uses cookies that are cached in Safari side when sends a request. We guess this behavior (probably a bug) causes session invalid.

We have been calling web api using Fetch, when using it with a "cache: no-store" option, the behavior was fixed:

fetch('/path/to/auth', {
    credentials: 'same-origin',
    cache: 'no-store'
});

At least this workaround is working fine for our case.

Thanks! This also works for us. We're doing jquery ajax requests and by adding key/value-pair "cache : false" to [settings] seems to solve the problem.

This doesn't appear to help with non-XHR requests at least.

For example, I am using the Fetch API to send a request to the server to authenticate. The server then sets an auth cookie in the response, and then I redirect to a server-rendered page that requires the auth cookie:

function logIn() {
    fetch('@Url.Action("Login")', {
        method: 'POST',
        cache: 'no-store',
        credentials: 'same-origin'
    })
    .then(() => {
        window.location.href = '@Url.Action("Index")';
    });
}

I am also making a similar fetch and redirect for the logout. When I close the home screen web app and re-open it after logging in or out, I can still reproduce the same issue as before where the cookie is not sent when it should be sent, or is sent when it should have been deleted. I also tried setting cache control headers on the responses, and that didn't seem to help.

I have only ever been able to reproduce this when closing and re-opening the home screen web app. As long as I keep it open and navigate from page to page via JavaScript, the cookies work as expected.

I am wondering whether it is necessary to set the cache-control header on every single request in order to avoid the buggy behavior, which of course is not possible with non-XHR requests. After your initial authentication requests, are you sending the cache-control header on subsequent resource requests?

We have been actually aware of the issue in non-XHR requests, but have had no trouble because our app is a SPA. (The authentication and all the other requests are sent with the Fetch API.)

In case of non-XHR requests, we think maybe you can solve it with appending a one-time query string at the end of the URL like this:

    window.location.href = '/foo' + '?_=20171013123456';

Sending cache control headers on the response has no effect on this issue.

Turns out I was able to reproduce this behavior entirely in JavaScript:

https://github.com/bencompton/ios11-cookie-set-expire-issue

It seems that setting or expiring a cookie, and then closing and re-opening the home screen web app causes the cookie to intermittently be in the incorrect state.

Just tried in 11.1 B5, and was still able to reproduce.

This is happening on this end too. I had the cookies show on the page just as a test and they don't match the current cookies the user is signed in with. Trying the no-cache jQuery code right now!

As a follow up, adding:

$.ajaxSetup({ cache: false });

before any ajax/get/post calls were made fixed the issue on this end!

Is this issue resolved? Are you seeing the issue with ios 11.3 as well?