HTML5 manifest frame behind basic Auth?

Question

I have a website that uses HTML5 caching and works great.

When I secure a site with Basic Auth (.htpasswd), caching does not seem to work. Ideally, I would like the site to cache for authenticated users. My theory is that when they visit the site offline, the server doesn’t actually get there, and therefore the cached version is displayed.

Is it part of the HTML5 specification that pages are not cached if they are protected? I could not find any reference to this.

Has anyone successfully created a password-protected cacheable application?

I'm not sure if this is a specific browser, but I'm testing in Safari - this is an application for iPad.

Thanks in advance

Answer 1

Some other people complained about the same issue on iOS 3.x and said that moving the manifest file outside the auth directory seems to fix it: http://lists.apple.com/archives/safari-iphone-web-dev/2010 /Sep/msg00000.html

I managed to solve the problem with the .htaccess file in the corresponding folder, which looked like this:

AddType text/cache-manifest .manifest <FilesMatch "your.manifest"> Order Allow,Deny Allow from all </FilesMatch> 

Answer 2

This is actually called CORS because the browser processes the request as a cross-source.

A good solution is to add crossorigin='use-credentials' to the manifest definition, like so:

 <link rel="manifest" crossorigin="use-credentials" href="/manifest.json"> 

Then it will pass your credentials into the manifest request.

More about this option :: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes

Answer 3

I had the same problem. Authentication broke or disabled JS on the page that triggered the cache manifest when we launched the application in full screen from the main screen.

As a job, starting with a mobile safari, we save the page on the main screen, which is a duplicate version of the page from which we want our cache manifest to be executed. Then, as soon as you start the page from the main screen, we forward the duplicated page to the real page on which the cache manifest works.

This causes the login, but does not interrupt JS from the cache manifest, as it is technically requested on our "fake page", although the user is immediately redirected to the correct page, where their cache download then starts successfully.

This seems like a bug in the full screen mode of mobile Safari. Hopefully these things will be fixed in a future release. Hope this helps.

---

UPDATE: the above fix did not finish working for us, since the fake intro page is not included in the manifest, so it does not load after offline work. bummer. we ended up just launching caching from a mobile safari, so any updates made should be done through the browser, and not in full screen mode.

Answer 4

A bit late, but here is the solution .