We now know this is an issue with IOS 11.3, and seems to target only Ipad.
When requesting ressources through appcache, the cookies are discarded. If your ressources are behind some authentication. They will be redirected to your authentication page.
As mentioned by Apple, we tried experimentation feature on/off.
Removing authentication for ressources is not a valid permanent option.
We are looking for solutions while the next version of IOS hopefully fix this problem which seem the case with 11.4 beta 2. Changes are to be as minimal as possible to reduce risks.
Following informations are the process we when through when trying to solve our problem. To this day, no valid solutions have been attempted. Service Workers being the most plausible path.
Day 1
We have an application which was running fine in production for a while (almost a year since last deployment).
Our application use app cache to enable offline mode when wifi is not available. Our application is mostly used on ipad with safari and some surface pro with chrome. Currently most cases are reported with ipad.
In the last few day, more and more users start to have problem loading the cache. We have been able to reproduce the probleme on an ipad after updating to 11.3 (could not reproduce on iphone 11.3) and using google chrome desktop incognito mode on dev machine. Application work on an older iPad we have which is at version 10.3.3.
--Application Cache Error event: Resource fetch failed (2) http://localhost:63330/client/vendor/kendo-ui/kendo.all.js--
Fact
- It always block on the same files, after some testings it seems to be all files bigger than 1.2Mb, in this case kendo is 4.7Mb and the minified one is 1.7Mb.
- Fiddler does not report any error, all files status response is 200
Guess
1. An update to safari and chrome might have changed
2. An ipad setting might have been changed by admins
3. An update to windows or ios, might have changes something
Since safari and ios follow the same release (29 Mar 2018), they are probably linked and the most likely guess, does anyone have an idea why this might happen?
Could not find much on apple support page of changes for 11.3
https://support.apple.com/en-ca/HT208067
https://support.apple.com/en-ca/HT201222
Update Monday 9 april 2018
We have been able to reproduce the issue both by debugging an Ipad and on the mac mini we have. However, the problem is different and for this reason we currently discarded what we found on Chrome on our desktop in incognito.
Here are the new facts:
[Warning] ApplicationCache is deprecated. Please use ServiceWorkers instead. (192.168.0.152, line 2)
[Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (cache.manifest, line 0)
[Error] Application Cache manifest could not be fetched, because the manifest had a 401 response.
[Error] 2018-04-09 12:01:51 : APPLICATION CACHE error
logMsg (logDecorator.js:111)
error (logDecorator.js:128)
(fonction anonyme) (applicationCacheUpdateSrv.js:121)
dispatch (jquery-1.10.2.js:5109)
handle (jquery-1.10.2.js:4780)
- After effect of solving authentication, we have problems with IDBDatabase, might be related to Authorization we removed (currently under investigation)
IndexedDB request error (get all rapports) -> NotFoundError: Failed to execute 'transaction' on 'IDBDatabase': One of the specified object stores was not found.
We found this by using Charles Proxy for Mac. For this reason, we removed authentication to our statics files and Home page. This seems to work, but our files would be public which is not really an option.
Similar questions: Cache-Manifest How to handle authentication cookies?
Update Monday 10 april 2018
IndexDB error are not related. Databases were not initialized properly due to authorization missing.
We currently added an alternative home page where authorization is not required instead of removing authorization from the default home page. It would be called by the manifest cache and downloaded properly.
Update Monday 12 april 2018
We tried to secure the static files, we ended up with adding a token in the query url. While it work and we can authenticate the request (note that since we do not have cookies to authenticate the user, the authentication is far from flawless), the Url is now different than what was requested in the cached Home page and make the custom authentication worthless by itself.
We would need to also rewrite all the url for the cached page base the token genereted by the user. In our cases, it involve throwing out the ASP.Net MVC Bundle feature to maybe make a custom one? At this point, we think it might just be easier to try ServiceWorker since appcache is deprecated. This does not guarantee cookie will be passed on with ServiceWorker...
Update Monday 19 april 2018
We had some return from Apple yesterday. They asked be try Prevent Cross-Site Tracking property (both on and off) in Settings > Safari and also try Experimental feature in Settings > Safari > Advanced > Experimental (mentionning ServiceWorkers, but tried them all)
Unfortunately it didn't change anything for me at the moment.
Note: strikethrough some part that were not related directly to the issue
Update Friday 25 may 2018
Added a section to the top to resume the situation and make the question more to the point.
As of 25 april 2018, we tried iOS 11.4 beta and it seem to resolve the issue. According the the deployement timeline, it should be available in about a month according to this.
However until then moving to service workers might be a good idea.
Here is an example from google.
Here is a video which gives an introduction to the subject
I will add an example if we get to move to Service workers