I'm currently hard at work developing my first Web application, and I have stumbled hard upon an issue on the iOS mobile-devices' Safari Browser.
If I create a cookie set to expire in x days (basically any cookie created, session-only or otherwise), and hard-reset the browser on the phone (as in closing the app entirely or restarting the phone), the cookie is destroyed.
Why is that? And how can I avoid it?
The same thing happens with objects stored in LocalStorage.
Also, if it can not be avoided, what other way of storing my app-data should I use? Server-side storage is last resort here.
The phone settings have been checked, nothing indicates that the browser is rejecting- or is set to clear cookies on session/app exit.
As Shivan Raptor said, important data should be stored server-side.
After some fiddling, I also found that localStorage apparently survives app hard-reset, whereas cookies do not.
Closing.
Related
I'm developing a social media site. Over the last three months, I have noticed that a few percent of users are suddenly losing their cookies on iOS.
I investigated the circumstances and found that
It is not in private mode.
One day the cookie suddenly disappears. Once this happens, the cookie disappears within a few minutes or hours, no matter how many times the user logs in.
I have tried every setting to reproduce this on my iPhone. This should occur simply by changing some setting such as privacy in chrome, but I have not been able to reproduce it.
My website sets the cookie 'expires' field to six months. Most users do not lose their cookies.
Chrome goes into the background, stops, and when Chrome restarts, all cookies from all sites disappear.
I asked the user to try another website that uses cookies and they all disappeared as well.
Cookies only disappear when Chrome goes into the background.
The nginx access log shows that no cookie was sent.
This is happening on iOS 16.
I have not tested what happens when the iPhone is initialized.
I've asked users to check what happens in safari.
Do you have any idea what the solution might be?
The frequency of occurrence led me to believe that this issue must occur worldwide, but I could not find any information on it. Probably because most people use apps instead of the browser for services that require login.
I am having a problem tracking conversions on Apple devices. This is the simplified scenario:
After login. User lands on page 1, behind the scenes, we push-piece of information into local storage specifying the original subscription date.
A GTM variable is created to hold this value, and when the conversion happens we push the variable value (subscription date) into the custom GA dimension ( to understand conversion velocity ).
This works fine on other devices except on Apple (data is missing). Is there any other way to persist piece of data from page to page on apple devices besides cookies and (or) local storage?
Well, it would be best to debug the issue properly. Actually reproduce the misbehavior of apple devices. And narrow down the problem. Also, figure out if this behavior depends on a device or on Safari. It's likely that it's about the browser rather than device.
It may be connected to nuances of local/session storage management in Safari. I would suggest trying a different kind of client-side storage.
It may also be connected to Apple's old PR stunt with their ITP efforts: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
We normally solve this issue with a backend mirror that resets cookies that we need to be persistent. That way, cookies become first-party and the ITP limitations are relaxed. There's nuance to this approach, however. For example, having it universally resetting any cookie may be a security issue, so cookie names and their values should be validated on that backend mirror.
If you have to go this far to fix the issue, you may as well consider starting using the server-side GTM container altogether.
I have authorization in my app that happens through POST-request to the server. In response I receive json file and cookie.
I want prevent user to enter credentials every time. So the question is how to store cookies (session only cookie) between app launches. I concern here 3 cases:
User pressed "Home" and returned to the app before app was terminated by iOS
User pressed "Home" and returned to the app after app was terminated by iOS
User forced quit from app by swiping-out it from multitasking
It seems that i can use something like this:
NSHTTPCookieStorage.sharedHTTPCookieStorage().cookiesForURL(NSURL(string: "url")!)
But is it secure and will it persist in case 2 and case 3?
I've been working on similar iOS issues for the past few weeks.
Depending upon just how secure the credentials need to be, I'd suggest looking into using the browser's localStorage functionality to resolve this, rather than using cookies.
localStorage and sessionStorage are far easier to manipulate than cookies, and cross domain protections help avoid both user manipulation and 3rd party attempts.
If one was dealing with almost any other browser, one would generally use sessionStorage, since the values are preserved per log on session. But, iOS on mobile devices wil purge session storage far too frequently, rendering it useless.
The danger of using localStorage is that values persist between browser sessions. Where this becomes an issue is if a legit user logs in from a 3rd party device, the credentials are retained on that device unless the user has a way purging them (which is easy to accomplish using javascript).
The advantages of using sessionStorage and localStorage are:
1. ease of manipulation compared to cookies
2. no need to keep posting back cookies values to the server
3. less server overhead
note that on iOS in particular, if Private Browsing is enabled, both session and local storage are disabled.
I am using the HttpContext.Current.Session.IsNewSession to decide on what page to show when my MVC4 application launches.
This works great on desktop, iOS safari.
However on iOS Chrome, every time I close the browser (actually close tabs and close the application from the task manager) and relaunch it the IsNewSession is always false.
I am guessing it uses the session cookie ASP.NET_SessionId to track this as there is a new cookie value when I close my desktop or safari.
However on iOS Chrome, when I close and relaunch the cookie has the old value - which I am guessing is the root of the issue.
So why does iOS/Chrome not clear my ASP.NET_SessionId cookie even though it should be a Session cookie and deleted when the browser is closed.
Thanks.
I suspect this is because of a design feature of many modern mobile operating systems whereby apps don't really close when you might think.
With desktop applications you have a lot more screen real estate and so it's easier to manage windows and multitask. So closing applications feels natural and necessary when you're done with it.
With mobile applications, however, there is more of a focus on the user being able to open and switch between applications seemlessly and so the concept of closing or minimising apps is abstracted away and taken care of by the operating system.
This means that when you close Chrome, it's not really closing (and may not close at all before you enter the app again). Therefore the session is never cleared.
If you force close the app then your function will work as expected.
There's no elegant work-around that I can think of for your problem. One idea is to store the time of last activity for the user and if it's greater than, for example, 5 minutes, then you can show them your startup page.
As I understand it, if I have code that creates a cookie without an explicit expiry time, it lasts for the duration of the browsing session (e.g. until the user closes their browser).
How does this apply to mobile devices, specifically iOS, where you never really quit Safari?
Cookies in Safari on the iPhone are stored in a property list file.
They stay there until the user manually clears their cookies on their device.
As I understand it, if I have code that creates a cookie without an explicit expiry time, it lasts for the duration of the browsing session (e.g. until the user closes their browser).