基本身份验证背后的 HTML5 清单缓存？
我有一个使用 HTML5 缓存并且运行良好的网站。
当我使用基本身份验证 (.htpasswd) 保护网站时，缓存似乎不起作用。理想情况下，我希望网站为经过身份验证的用户缓存。我的理论是，当他们离线访问该网站时，服务器实际上并未受到攻击，因此会显示缓存的版本。
如果页面受到保护，则不会被缓存，这是 HTML5 规范的一部分吗？我找不到任何对此的参考。
有人成功创建了受密码保护的可缓存应用程序吗？
我不确定这是否是特定于浏览器的，但我正在 Safari 中进行测试 - 这是一个 iPad 应用程序。
提前致谢
I've got a site that's using HTML5 caching and working lovely.
When I protect the site using Basic Auth (.htpasswd) the caching doesn't seem to work. Ideally I'd like the site to cache for authenticated users. My theory is that when they visit the site offline the server isn't actually being hit and so the cached version is displayed.
Is it part of the HTML5 specification that pages aren't cached if they are protected? I couldn't find any reference to this.
Has anyone successfully created a password protected cacheable application?
I'm not sure if this is browser specific but I'm testing in Safari - it's an iPad application.
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这实际上是由 CORS 引起的，因为浏览器将请求视为跨源。
一个好的解决方案是将
crossorigin='use-credentials'添加到清单定义中，如下所示：然后，这会将您的凭据传递给清单请求。
有关此设置的更多信息： https://developer.mozilla.org/ en-US/docs/Web/HTML/CORS_settings_attributes
This is actually caused by CORS because the browser treats the request as cross-origin.
A good solution is to add
crossorigin='use-credentials'onto your manifest definition, like so:This will then pass your credentials over to the manifest request.
More info on this setting:: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes
其他一些人在 iOS 3.x 上抱怨同样的问题，并表示将清单文件移到 auth 目录之外似乎可以解决问题：
http://lists.apple.com/archives /safari-iphone-web-dev/2010/Sep/msg00000.html
我能够使用相关文件夹中的 .htaccess 文件解决该问题看起来像这样：
Some other people were complaining about the same problem on iOS 3.x and said moving the manifest file outside of the auth directory seemed to fix things:
http://lists.apple.com/archives/safari-iphone-web-dev/2010/Sep/msg00000.html
I was able to work around the problem with an .htaccess file in the folder in question that looked like this:
我也有同样的问题。当我们从主屏幕以全屏模式启动应用程序时，身份验证破坏或禁用了启动缓存清单的页面上的 JS。
作为解决方法，我们从移动 Safari 中将一个页面保存到主屏幕，这是我们希望运行缓存清单的页面的重复版本。然后，一旦您从主屏幕启动页面，我们会将重复的页面转发到我们正在运行缓存清单的真实页面。
这会提示登录，但不会破坏运行缓存清单的 JS，因为从技术上讲，它是在我们的“假页面”上提示的，尽管用户随后会立即转发到正确的页面，然后成功开始缓存下载。
这似乎是移动 Safari 全屏模式中的一个错误。希望这些问题能够在未来的版本中得到修复。希望这有帮助。
更新：上述修复最终对我们不起作用，因为假的介绍页面未包含在清单中，因此一旦离线就不会加载。真糟糕。我们最终只是从移动 Safari 启动缓存，因此任何更新都需要通过浏览器进行，而不是在全屏模式下进行。
I had this same problem. The authentication broke or disabled the JS on the page which initiated the cache manifest when we launched the app in full screen mode from the home screen.
As a work around, from mobile safari we save a page to the home screen which is a duplicated version of the page that we want our cache manifest to run from. Then once you launch the page from the home screen we forward the duplicated page to the real page that we are running cache manifest from.
This prompts the login but does not break the JS running the cache manifest since it is technically prompted on our 'fake page' though the user is then immediately forwarded to the correct page where their cache download then successfully begins.
This seems like a bug in mobile Safari's full screen mode. Hopefully such things will be fixed in a future release. Hope this helps.
UPDATE: the above fix did not end up working for us since the fake intro page is not included in the manifest, so it doesn't load once offline. a bummer. we ended up just initiating the caching from mobile safari, so that any updates made need to be made through the browser and not in full screen mode.