Chrome 中显示的原始标记而不是 SSO 重定向 - IdentityProvider.SendSAMLResponseByHTTPPost
Raw markup displayed in Chrome instead of SSO redirect - IdentityProvider.SendSAMLResponseByHTTPPost
我们正在使用 ComponentSpace.SAML2.Profiles.SSOBrowser.IdentityProvider 并调用 SendSAMLResponseByHTTPPost 来执行 SSO 并将用户重定向到另一个 URL。
这在 IE 和 Firefox 上运行良好,但在 Chrome 上,浏览器中显示以下内容
<html xmlns="http://www.w3.org/1999/xhtml">
<body onload="document.forms.samlform.submit()">
<noscript>
<p><strong>Note:</strong> Since your browser does not support Javascript, you must press the Continue button once to proceed.</p>
</noscript>
<form id="samlform" action="https://REDACTED URL" method="post">
<div>
<input type="hidden" name="SAMLResponse" value="REDACTED SAMLResponse"/>
<input type="hidden" name="RelayState" value="https://REDACTED URL"/>
</div>
<noscript>
<div><input type="submit" value="Continue"/></div>
</noscript>
</form>
</body>
</html>
这是在本地环境中使用相同代码在 Chrome 上工作。
我们遇到问题的环境中存在一些 SSL 证书问题。不确定这是否相关 - Chrome 是否比其他浏览器更严格?
这是因为存在 header "x-content-type-options: nosniff",这会阻止 Chrome 自行确定 MIME 类型。明确添加 Content-Type header 解决了这个问题。
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
感谢您提供信息。
我们还没有在 Chrome 或任何其他浏览器中看到这一点。
跟踪 HTTP 流量我发现包含以下 header:
Content-Type: text/html;字符集=utf-8
我想知道在你的场景中是否有中间节点剥离了这个header?
我们正在使用 ComponentSpace.SAML2.Profiles.SSOBrowser.IdentityProvider 并调用 SendSAMLResponseByHTTPPost 来执行 SSO 并将用户重定向到另一个 URL。
这在 IE 和 Firefox 上运行良好,但在 Chrome 上,浏览器中显示以下内容
<html xmlns="http://www.w3.org/1999/xhtml">
<body onload="document.forms.samlform.submit()">
<noscript>
<p><strong>Note:</strong> Since your browser does not support Javascript, you must press the Continue button once to proceed.</p>
</noscript>
<form id="samlform" action="https://REDACTED URL" method="post">
<div>
<input type="hidden" name="SAMLResponse" value="REDACTED SAMLResponse"/>
<input type="hidden" name="RelayState" value="https://REDACTED URL"/>
</div>
<noscript>
<div><input type="submit" value="Continue"/></div>
</noscript>
</form>
</body>
</html>
这是在本地环境中使用相同代码在 Chrome 上工作。
我们遇到问题的环境中存在一些 SSL 证书问题。不确定这是否相关 - Chrome 是否比其他浏览器更严格?
这是因为存在 header "x-content-type-options: nosniff",这会阻止 Chrome 自行确定 MIME 类型。明确添加 Content-Type header 解决了这个问题。 https://www.owasp.org/index.php/List_of_useful_HTTP_headers
感谢您提供信息。
我们还没有在 Chrome 或任何其他浏览器中看到这一点。
跟踪 HTTP 流量我发现包含以下 header:
Content-Type: text/html;字符集=utf-8
我想知道在你的场景中是否有中间节点剥离了这个header?