blocks|key|2251365|text|根据RFC+1738，当请求资源时，客户端不向服务器发送锚标记。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2251366|锚标记用于标识资源中的位置，而不是服务器上的其他资源。为了识别资源中的位置，客户端需要从服务器获取完整的资源，并且这个过程不需要传输关于片段的信息(因为它对服务器没有任何意义)。|2251367|如果您确实希望将片段字符(#)发送到服务器，则需要在查询字符串中对其进行编码，否则客户机(浏览器)在将请求发送到服务器时将忽略URL的该部分。|2251368|编辑：|style|BOLD|2251369|我不知道任何真正的解决方案，但是要解决这个问题，您需要在客户端的某个地方保存完整的返回URL+(带有锚标记)，因为服务器对锚一无所知。为此，您可以使用SessionStorage+(webstorage.asp)临时存储ReturnUrl，直到登录过程完成为止。请注意，旧浏览器(如<=+IE7)不支持它。|2251370|在这种情况下，解决办法应该如下所示：|2251371|<script>
++++if(typeof(sessionStorage)+==+'undefined')
++++{
++++++++sessionStorage+=+{
++++++++++++getItem:+function(){},
++++++++++++setItem:+function(){}
++++++++};
++++}

++++window.onload+=+function+()
++++{
++++++++var+key+=+'ReturnUrl';

++++++++//try+to+get+last+returnUrl+with+anchors
++++++++var+returnUrl+=+sessionStorage.getItem(key);

++++++++//if+we+got+something,+do+the+navigation
++++++++if(returnUrl+!==+undefined+&&+returnUrl+!==+document.URL)
++++++++{
++++++++++++//clean+it+up
++++++++++++sessionStorage.setItem(key,+null);
++++++++++++//navigate+to+last+URL
++++++++++++window.location+=+returnUrl;
++++++++}
++++++++else
++++++++{
++++++++++++//store+url+
++++++++++++sessionStorage.setItem(key,+document.URL);
++++++++}
++++}
</script>|code-block|syntax|javascript|2251372|PS。如果有一些语法错误，请原谅我，因为我是从头上写下来的，没有尝试过。|2251373|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ietf.org/rfc/rfc1738.txt|1|http://www.w3schools.com/html/html5_webstorage.asp^0|2|8|0|0|0|0|0|3|0|2J|E|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|1C|8|@$A|1D|B|1E|J|K]]|9|@]|C|$]]|$1|L|3|M|5|6|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]]|C|$]]|$1|N|3|O|5|6|7|1J|8|@]|9|@]|C|$]]|$1|P|3|Q|5|R|7|1K|8|@]|9|@]|C|$S|T]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]|14|$5|Z|10|11|C|$12|15]]]]

According to <a href="http://www.ietf.org/rfc/rfc1738.txt" rel="nofollow noreferrer">RFC 1738</a> anchor tags are not sent by the client to the server, when requesting for a resource. 

Anchor tags are used to identify a location within a resource and not a different resource on the server. In order to identify the location in the resource, the client needs to fetch the complete resource from the server, and this process need not involve transfer of information about the fragment (as it does not mean anything to the server).

If you do wish to send the fragment character (#) to the server, then you'll need to encode it in the query string, or the client(browser) will simply ignore that section of the URL when it sends the request to the server.

EDIT:

I don't know any real solution but to work around this issue you need to save your full return URL (with anchor tags) somewhere on the client side, because server don't know anything about anchors. For that you could use SessionStorage (<a href="http://www.w3schools.com/html/html5_webstorage.asp" rel="nofollow noreferrer">http://www.w3schools.com/html/html5_webstorage.asp</a>) to temporary store ReturnUrl until login process is completed. Please note that it won't be supported on older browsers (like &lt;= IE7).

In that case workaround would look something like this:

<pre><code>&lt;script&gt;
 if(typeof(sessionStorage) == 'undefined')
 {
 sessionStorage = {
 getItem: function(){},
 setItem: function(){}
 };
 }

 window.onload = function ()
 {
 var key = 'ReturnUrl';

 //try to get last returnUrl with anchors
 var returnUrl = sessionStorage.getItem(key);

 //if we got something, do the navigation
 if(returnUrl !== undefined &amp;&amp; returnUrl !== document.URL)
 {
 //clean it up
 sessionStorage.setItem(key, null);
 //navigate to last URL
 window.location = returnUrl;
 }
 else
 {
 //store url 
 sessionStorage.setItem(key, document.URL);
 }
 }
&lt;/script&gt;
</code></pre>

PS. Bear with me if there are some syntax errors because I wrote it down from top of my head and didn't try it.

blocks|key|705718|text|你基本上有两个选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|705719|避免使用location.hash+(至少在支持HTML5+5的浏览器上使用HTML5+5的pushState；和/或提出一种在应用程序中生成permalinks的方法--+Google组这样做)|unordered-list-item|offset|length|style|CODE|705720|使用JavaScript执行重定向。也就是说，不要从服务器发送重定向，而是使用一些脚本发送一个空的HTML页面，该脚本接受完整的URL+(带有散列)，并使用location.assign()或location.replace()进行重定向。如果运气好(取决于服务器)，您将在身份验证后重定向到这个完整的URL。|705721|当然，您可以两者都做:如果链接是深入链接到应用程序，那么执行重定向(即假设没有散列)，否则发送一个带有JS的页面，以确保您不会丢失散列中的任何状态。|705722|最后，最明显的第三种解决方案，远非理想:不要做任何事，并试图教育用户，当他们需要(重新)认证时，他们应该重新粘贴URL或重新单击链接或重新单击书签。|705723|entityMap^0|0|4|D|1A|9|0|26|H|2O|I|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@$E|S|F|T|G|H]|$E|U|F|V|G|H]]|9|@]|A|$]]|$1|I|3|J|5|D|7|W|8|@$E|X|F|Y|G|H]|$E|Z|F|10|G|H]]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|P|$]]

You basically have two options:

<ul>
<li>avoid using <code>location.hash</code> (use HTML5's <code>pushState</code> instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)</li>
<li>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 <code>location.assign()</code> or <code>location.replace()</code>. With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.</li>
</ul>

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.

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.

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 <a href="https://stackoverflow.com/q/7270066/223837">this StackOverflow question</a>, and AppEngine, see <a href="https://code.google.com/p/google-web-toolkit/issues/detail?id=7101#c14" rel="nofollow noreferrer">this GWT bug comment</a>) lose the original 'URL fragment', i.e. the part after the #-sign.

What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) <a href="http://example.com/myapp/somepage?some=parameter#somewhere" rel="nofollow noreferrer">http://example.com/myapp/somepage?some=parameter#somewhere</a>. This makes the browser request (2) <a href="http://example.com/myapp/somepage?some=parameter" rel="nofollow noreferrer">http://example.com/myapp/somepage?some=parameter</a>, 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.

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

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?

The obvious workaround is to avoid URL fragments, as suggested in <a href="https://stackoverflow.com/a/7270108/223837">this answer</a>. 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?

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

URL fragment lost as part of SAML token authentication; workaround / standard pattern?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

几种web应用程序身份验证协议(如WS-Federation和SAML协议，即所谓的“被动”协议，以及显然也是ASP.NET Forms身份验证，见和AppEngine，见)丢失了原始的'URL片段‘，即#-符号后面的部分。所发生的情况大致如下:在干净的浏览器中(所以没有缓存的信息/cookie/登录信息)，我打开了 ...

问URL片段丢失作为SAML令牌身份验证的一部分；解决方法/标准模式？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问URL片段丢失作为SAML令牌身份验证的一部分；解决方法/标准模式？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问URL片段丢失作为SAML令牌身份验证的一部分；解决方法/标准模式？
EN