我正在使用 WIF 和使用 ThinkTecture STS 的联合安全模型。
当我尝试请求 url: http://domain.com/#page时,WIF 不会在身份验证后重定向到正确的页面。
wctx中的ru参数不包含/#path的正确路径。相反,它忽略了哈希和它之后的所有内容,所以ru参数只是/。没有哈希的普通网址可以正常工作。
是否有针对此的锻炼或我的网址格式不正确?
有什么建议么?
我正在使用 WIF 和使用 ThinkTecture STS 的联合安全模型。
当我尝试请求 url: http://domain.com/#page时,WIF 不会在身份验证后重定向到正确的页面。
wctx中的ru参数不包含/#path的正确路径。相反,它忽略了哈希和它之后的所有内容,所以ru参数只是/。没有哈希的普通网址可以正常工作。
是否有针对此的锻炼或我的网址格式不正确?
有什么建议么?
您可以通过发出 JavaScript 来执行重定向来保留哈希部分,而不是立即重定向。JavaScript 代码可以通过 window.location.hash 访问哈希部分,并使用它来构建 ru。
您需要将页面配置为允许未经身份验证的用户(这样 WIF 被动身份验证不会启动)。然后您可以在页面代码中处理未经身份验证的用户。
您可以在应用程序启动代码(例如 Web 窗体中的 Global.asax.cs)中挂钩 FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider 事件。
例如(网络表单):
public class Global : HttpApplication
{
protected void Application_Start(object sender, EventArgs e)
{
FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider
+= this.RedirectToIdentityProviderViaJavaScript;
}
const string RedirectHtml =
@"<html>
<head>
<script type='text/javascript'>
function authenticate(url, utcTimeString) {{
var ru = window.location.pathname + (window.location.hash || '');
var wctx = 'rm=0&id=passive&ru=' + encodeURIComponent(ru) + '&wtc=' + encodeURIComponent(utcTimeString);
url += '&wctx=' + encodeURIComponent(wctx);
window.location = url;
}}
</script>
</head>
<body onload=""authenticate('{0}', '{1}');"">
</body>
</html>";
private void RedirectToIdentityProviderViaJavaScript(object sender, RedirectingToIdentityProviderEventArgs e)
{
var fam = FederatedAuthentication.WSFederationAuthenticationModule;
var msg = new SignInRequestMessage(new Uri(fam.Issuer), fam.Realm);
var stsUrl = msg.WriteQueryString();
var utcTime = WebPageRoutines.EncodeUtcTimeString(DateTime.Now);
var html = string.Format(RedirectHtml, WebPageRoutines.JavascriptEncode(stsUrl), WebPageRoutines.JavascriptEncode(utcTime));
Response.ClearContent();
Response.Write(html);
Response.Status = "200 OK";
Response.End();
}
}
被警告你不能混合?使用这种方法的 # 部分参数。ru 在 STS 重定向(Thinktecture IdentityServer v2)中幸存下来,但 WIF 似乎在来自 STS 的 POST 之后的最终重定向上搞砸了。
它将放置 ? # 部分之后的部分。
http://www.somewebsite.com/page?param=1&other=2#hashbit
变为:
http ://www.somewebsite.com/page#hashbit?param=1&other=2
最好使用 CreateSignInRequest 从 web.config 中获取所有参数。猜猜它解决了查询字符串的问题。使用 MVC 的示例
const string redirectHtml =
@"<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
<script type='text/javascript'>
function authenticate(url) {{
var ru = window.location.pathname + (window.location.hash || '');
window.location = url.replace('REPLACEWITHURL', encodeURIComponent(ru));
}}
</script>
</head>
<body onload=""authenticate('{0}');"">
</body>
</html>";
var authenticationModule = FederatedAuthentication.WSFederationAuthenticationModule;
var message = authenticationModule.CreateSignInRequest("passive", "REPLACEWITHURL", false);
var stsUrl = message.WriteQueryString();
var html = string.Format(redirectHtml, HttpUtility.JavaScriptStringEncode(stsUrl));
filterContext.Result = new ContentResult { Content = html };
看起来它的浏览器没有将 url 的哈希部分发送回服务器。我相信这是一个 HTTP 标准,因为哈希部分最初仅用于客户端锚标记。
有使用 ajax/javascript 的变通方法,但由于我使用的是简单的 GET 请求,这似乎是不可能的。
看到这些类似的问题,这解释了问题......
这就是哈希碎片的全部意义——它们最终不会出现在服务器上。