Summary: | REGRESSION (iOS 17.x): Session cookies being reset randomly in a Home Screen web app | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ricardo Cristino <ricardo.cristino> | ||||
Component: | Website Storage | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Critical | CC: | afiestaso, ap, beidson, cdumez, joao.duque, karlcow, kilian.croese, m_finkel, miguel.freitas, sihui_liu, webkit-bug-importer, wilander | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari 17 | ||||||
Hardware: | iPhone / iPad | ||||||
OS: | iOS 17 | ||||||
URL: | https://ricardocristino.outsystemscloud.com/DUMMY/ | ||||||
Attachments: |
|
Description
Ricardo Cristino
2024-04-08 05:40:13 PDT
Thank you for the report! Would it be possible to share more detailed steps to reproduce, with a URL to test with? Created attachment 470815 [details]
Video of the issue
We have a PWA installed on iPad 17.4.1. This device uses Safari as the default browser. We install the app as a PWA (access the app through the browser and add it to the home screen). Then, we open it, click login, and choose an item from the list. If the issue does not happen, close the app and start over. At some point, a 403 error happens. Usually one needs more than 5 attempts.
I'm working on providing a public endpoint for you to test it, we don't have one at the moment. Hi team, I've attached a link to an application where the behavior is replicated (in the URL field of the bug). Access that URL on the browser in iPad 17.4.1 and add it to the Home Screen to run as a PWA. Then repeat these steps: 1. Open the PWA and the previous session is lost; 2. Click "Login with Username" button to get new session cookies; 3. You'll get redirected to a screen called Market with a list. You can click one of the items from the list and wait 1 or 2 seconds to see if the 403 error shows up in an alert message. No need to wait much more than this. 4. If the error does not pop up, just close the app and repeat the whole process again until a 403 error happens. Notice that closing the PWA causes the previous session cookies to be lost (we don't know if this is expected). Right after installing the app for the first time, the session cookies were not getting lost when closing and reopening the app. I kept opening and closing it multiple times (less than 10 times). At some point, every time I closed the app, the session cookies were getting lost upon reopening. This is also a misbehavior that is very inconsistent from my perspective. Why does the PWA lose the session when you close and reopen it? Why is this behavior not consistent the first times you close and reopen it? Regarding cookies A, B, and C that I mentioned earlier, their corresponding names in the app are "nr1Users", "nr2Users", and "Users". We are now receiving reports from more major companies about this same issue. Please consider this bug report an opportunity to prevent a large-scale issue. We are interested in cooperating to resolve this. Thank you Thank you! I cannot reproduce this on an iPhone with iOS 17.5 beta. Not getting any 403 alerts, and only saw the "Login with Username" screen once, after installing the app. I did force quit it a number of times. However, I did get to the "Login with Username" screen again, after rebooting the device. Which suggests that some state may be kept in memory even over force-quitting? And perhaps that process gets terminated in your case for some reason. I do not know much about how WebApp works architecturally, but I'll look for someone who would have insight. (In reply to Alexey Proskuryakov from comment #6) > Thank you! I cannot reproduce this on an iPhone with iOS 17.5 beta. Not > getting any 403 alerts, and only saw the "Login with Username" screen once, > after installing the app. I did force quit it a number of times. > > However, I did get to the "Login with Username" screen again, after > rebooting the device. Which suggests that some state may be kept in memory > even over force-quitting? And perhaps that process gets terminated in your > case for some reason. > > I do not know much about how WebApp works architecturally, but I'll look for > someone who would have insight. Hi Alexey, Thank you for following up. I could see your attempts on my back-office audits. Indeed, the error did not happen. It is usually difficult even for me to replicate it for the first time but, once it starts happening, it's very easy to get the 403. I would like to add that the people who have been able to replicate the error in this particular app were located in the European Union. Just in case there is any difference in the underlying technology used by our devices. And also, there is a logout link inside the Settings tab. You can force the logout from your app when you are not losing the session. You can click it a few times to see if you can initiate the reported behavior. After a few attempts, you can close the app without logging out and the session is lost anyways. Regards, And it's much easier to replicate on iPad 17.4.1. On iPhone, the error is much more difficult to replicate. Our users reported that they struggled a lot more to get that error on iPhone. I was unable to reproduce the 403 error on an iPad either, but there is clearly something quite wrong. - I had an iPad Pro, so bigger memory size may have masked the issue. - About half of the time, I needed to click the login button after relaunching, which was not the case on iPhone before. - Once, tapping the client card wouldn't do anything, I had to force-quit the webapp without getting to the last step. The needing to login aspect certainly looks wrong, it shouldn't be random whether we still have the cookies after relaunching. Just to make sure, by session cookies, do you mean cookies without any of the two Set-Cookie attributes Max-Age and Expires? (In reply to John Wilander from comment #10) > Just to make sure, by session cookies, do you mean cookies without any of > the two Set-Cookie attributes Max-Age and Expires? correct, they default to session when missing those values on the set-cookie header. Hello team, We have large companies under a lot of pressure due to the instability of their apps. As mentioned, this is affecting native apps as well (cordova-based). We just shared the PWA app as an example because it was the easiest way we could find to replicate the misbehavior. As some of these companies operate in highly regulated industries, they can be fined. Could you share with us the current status of the investigation? Regards, I believe that we have been suffering the same bug, although with a WKWebview. Some metadata that hopefully will help you locate the error. We started to get negative reviews around 2 months ago. Some users can reliable reproduce this every 24h or 48h. We added a log statement on every request using a WKNavigationDelegate that will check if the login cookie was present and also print getAllCookies. What we have been able to observe is that there is a ~30% chance that the first requests will not have any cookies, or at least they won't be available in the NavigationDelegate. After the third request or so cookies are sent. I took a look at the webkit source code and it seems that the cookie initialization is async. Perhaps this is simply a race condition? Hello team, I would like to add a few details here. As mentioned before, the authentication flow of our applications is as follows: 1. A user accesses an application for the first time; 2. The server replies with two set-cookie headers which define two persistent cookies (Max-Age of 1 year) with default values (let's call them cookies A and B); 3. These two cookies are always sent together with the "Cookie" header in the subsequent requests; 4. The user logs in and the server replies with three Set-Cookie headers: cookies A and B are changed to different unique values with session expiration (no Max-age); and a third session cookie C (no Max-age) is also created/modified; 5. Here, the user is authenticated, those 3 cookies are passed in the "Cookie" header to authenticate any request to the server. During our tests we also observed that the error could not be replicated if we change step 2: 2. The server replies with two set-cookie headers which define two session cookies (no max-age defined) with default values (let's call them cookies A and B). We hope these details can help your engineering team address this issue. I believe I was able to reproduce this awhile ago in iOS 17.5 and 17.5.1 I tried in the iOS 18 beta 2 (released yesterday) and was unable to reproduce. Unfortunately because it's *not* 100% reproducible, I'm not yet confident in the results, but if some other change has come in here and fixed this, then there's nothing left to explore. Have you had a chance to look in the iOS 18 beta(s) yet? Hi, If you used the link I provided to replicate the issue, there is no evidence in the logs that any error occurred this week. Regarding testing on iOS 18, I can have a look, but considering that even in the affected iOS versions the issue is not consistently replicated, I don't have a high degree of confidence that just because it does not happen on your iOS 18 tests it means that the issue was fixed. From the meetings with Apple regarding this topic, I was informed that the engineering team had been able to replicate and understand the issue but the root cause was still unknown. After all this time, considering the impact of this issue on our company and strategic customers, I was expecting to receive a more delicate message. For instance, what were the conclusions of your analysis, the possible root cause, and what was done in the most recent versions that could potentially mitigate this issue. I'm going to provide some feedback on the iOS 18 version, but please note that we might need some time to gather this information from a sample of our user base. Regards, Hi, I tried to check if there was evidence of the issue occurring on iOS 18 Beta, but there are still very few users with the beta version. It's a neglectable percentage of the total user base, so I can't still extract reliable numbers to say if the issue is occurring. But I'll keep an eye on it. We are receiving more and more complaints from users affected by this issue, mainly on iOS 17.4.1. We would really like to hear some feedback on the status of the investigation. Regards, Hello team, We continue to receive support requests from our customers regarding this issue. Could you please provide a status update on what has been done so far and what are your planned next steps? Almost two months have passed since Ricardo's request for a status update and no answer was provided. Please let us know if we can help you in any way. Regards, Miguel Freitas Hello team, We continue to receive support requests from our customers regarding this issue. Could you please provide a status update on what has been done so far and what are your planned next steps? Almost two months have passed since Ricardo's request for a status update and no answer was provided. Please let us know if we can help you in any way. Regards, Miguel Freitas |