URL片段作为SAML令牌身份验证的一部分丢失；解决方法/标准模式? [英] URL fragment lost as part of SAML token authentication; workaround / standard pattern?

问题描述

几种Web应用程序身份验证协议(例如WS-Federation和SAML协议，即所谓的被动"协议，以及ASP.NET Forms身份验证，请参见

Several web application authentication protocols (like WS-Federation and the SAML protocol, i.e., so-called 'passive' protocols, and apparently also ASP.NET Forms authentication, see this StackOverflow question, and AppEngine, see this GWT bug comment) lose the original 'URL fragment', i.e. the part after the #-sign.

发生的事情大致如下:在一个干净的浏览器中(因此没有缓存的信息/cookie/登录信息)，我打开URL(1) http://example.com/myapp/somepage?some=参数，服务器将我重定向到我的身份提供者(包括身份验证请求中的URL(2))，最终我被重定向回我的来源，即URL(2):这是唯一的服务器知道的URL.但是我想转到URL(1)，URL片段('anchor')已经丢失了，实际上已经在第一步中了.

What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) http://example.com/myapp/somepage?some=parameter#somewhere. This makes the browser request (2) http://example.com/myapp/somepage?some=parameter, the server redirects me to my identity provider (including URL (2) in the authentication request), and ultimately I'm redirected back to where I came from, which is URL (2): that is the only URL that the server knows about. But I wanted to go to URL (1), and the URL fragment ('anchor') has been lost along the way, actually in the first step already.

这似乎是这些协议的基本限制，因为服务器根本看不到URL片段.

This seems to be a fundamental limitation of these protocols, since the server never sees the URL fragment at all.

我知道，根据规范，当我导航到(1)时，浏览器会从服务器请求(2)，这导致了SAML协议，WS-Federation等上丢失碎片的限制.我的问题是:如何解决此限制?

I know that it according to specifications that the browser requests (2) from the server, when I navigate to (1), leading to this fragment-losing limitation on the SAML protocol, WS-Federation, etc. My question is: how do I work around this limitation?

明显的解决方法是避免URL片段，如此答案中所建议.但是，对于我们的特定Web应用程序来说，这不是很好，因为我们在单页GWT应用程序中使用了可添加书签的URL片段，以确保应用程序中的导航不会导致页面重新加载.

The obvious workaround is to avoid URL fragments, as suggested in this answer. However, for our specific web application that is not nice, since we use bookmarkable URL fragments in our single-page GWT application, to make sure that a navigation within our application does not cause the page to reload.

我的问题:在这种情况下还有哪些其他解决方法或标准模式?

My question: What other workarounds or standard patterns are there for this situation?

(我对GWT + SAML协议解决方案特别感兴趣.)

(I'm specifically interested in a GWT + SAML protocol solution.)

推荐答案

您基本上有两个选择:

• 避免使用location.hash(至少在支持HTML5的pushState上使用HTML5的pushState；和/或建议一种在应用内生成永久链接的方法– Google网上论坛会这样做那个)

• avoid using location.hash (use HTML5's pushState instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)

使用JavaScript进行重定向. IE.而不是从服务器发送重定向，而是发送一个空HTML页面，该页面带有一些脚本，该脚本采用完整的URL(带有 hash )，并使用location.assign()或location.replace()进行重定向.运气好的话(取决于服务器)，身份验证后您将被重定向到该完整URL.

do the redirection using JavaScript. I.e. instead of sending a redirect from the server, send an empty HTML page with some script that takes the full URL (with the hash) and does the redirection using location.assign() or location.replace(). With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.

您当然可以同时进行:如果链接是应用程序的深层链接，则进行重定向(即假设没有 hash )，否则发送带有JS的页面以确保您不会丢失哈希中存在的任何状态.

You can of course do both: if the link is a deep-link into the app, then do the redirect (i.e. assume there's no hash), otherwise send a page with JS to make sure you don't lose any state present in the hash.

最后是显而易见的第三种解决方案，远非理想:不做任何事情，并试图教育用户，当他们需要(重新)认证时，他们应该重新粘贴URL或重新单击链接或重新输入.点击书签.

And finally the obvious third solution, far from ideal: don't do anything, and try to educate users that when they needed to (re)authenticate then they should re-paste the URL or re-click the link or re-click the bookmark.

这篇关于URL片段作为SAML令牌身份验证的一部分丢失；解决方法/标准模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！