几种 Web 应用程序身份验证协议（例如 WS-Federation 和 SAML 协议，即所谓的“被动”协议，显然还有 ASP.NET Forms 身份验证，请参阅这个 StackOverflow 问题 https://stackoverflow.com/q/7270066/223837和 AppEngine，请参阅这个 GWT bug 评论 https://code.google.com/p/google-web-toolkit/issues/detail?id=7101#c14) 丢失原始的“URL 片段”，即 # 符号之后的部分。
发生的情况大致如下：在干净的浏览器中（因此没有缓存的信息/cookies/登录信息）我打开 URL (1)http://example.com/myapp/somepage?some=parameter#somewhere http://example.com/myapp/somepage?some=parameter#somewhere。这使得浏览器请求（2）http://example.com/myapp/somepage?some=parameter http://example.com/myapp/somepage?some=parameter，服务器将我重定向到我的身份提供者（包括身份验证请求中的 URL (2)），最终我被重定向回我来自的位置，即 URL (2)：这是服务器知道的唯一 URL关于。但我想转到 URL (1)，而 URL 片段（“锚点”）在途中已经丢失，实际上在第一步中就已经丢失了。
这似乎是这些协议的基本限制，因为服务器根本看不到 URL 片段。
我知道，根据浏览器从服务器请求 (2) 的规范，当我导航到 (1) 时，会导致 SAML 协议、WS-Federation 等出现片段丢失限制。我的问题是：如何做我可以解决这个限制吗？
明显的解决方法是避免 URL 片段，如中所建议的这个答案 https://stackoverflow.com/a/7270108/223837。然而，对于我们的特定 Web 应用程序来说，这并不好，因为我们在单页 GWT 应用程序中使用可添加书签的 URL 片段，以确保应用程序中的导航不会导致页面重新加载。
我的问题：对于这种情况还有哪些其他解决方法或标准模式？
（我对 GWT + SAML 协议解决方案特别感兴趣。）
你基本上有两个选择：
避免使用location.hash（使用 HTML5pushState相反，至少在支持它的浏览器上；和/或提出一种生成方法永久链接在您的应用程序中 - Google 网上论坛就是这样做的）
使用 JavaScript 进行重定向。 IE。不要从服务器发送重定向，而是发送一个空的 HTML 页面，其中包含一些采用完整 URL 的脚本（带有hash）并使用重定向location.assign() or location.replace()。如果运气好的话（取决于服务器），您将在身份验证后被重定向到该完整 URL。
您当然可以同时执行这两种操作：如果链接是应用程序的深层链接，则进行重定向（即假设没有hash），否则发送带有 JS 的页面以确保不会丢失任何内容state存在于hash.
最后是明显的第三种解决方案，远非理想：不执行任何操作，并尝试教育用户，当他们需要（重新）身份验证时，他们应该重新粘贴 URL 或重新单击链接或重新单击书签。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
