java - 为什么基本的 AUTH 框在 Chrome 中弹出两次而不是带有 spnego SSO 的 Firefox

Question

我有一个非常普通的 spnego SSO 设置，它针对 Active Directory 服务器进行身份验证。 IE SSO 包含 NEGOTIATE header cookie，它无需任何提示用户即可正确进行身份验证。 Firefox 和 Chrome 不包含 SSO cookie，因此会故障回复到基本身份验证。他们确实收到了正确的用户名和密码并正确登录。

然而，我的小烦恼是它在 Firefox 中提示一次，但在 Chrome 中提示输入密码两次。

关于为什么它会提示两次有什么想法吗？

以下设置的完整性:

<filter>

    <filter-name>SpnegoHttpFilter</filter-name>

    <filter-class>net.sourceforge.spnego.SpnegoHttpFilter</filter-class>

    <init-param>
        <param-name>spnego.allow.basic</param-name>
        <param-value>true</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.allow.localhost</param-name>
        <param-value>true</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.allow.unsecure.basic</param-name>
        <param-value>true</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.login.client.module</param-name>
        <param-value>spnego-client</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.krb5.conf</param-name>
        <param-value>xxxxxxxxxxxxx/krb5.conf</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.login.conf</param-name>
        <param-value>xxxxxxxxxxxx/login.conf</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.preauth.username</param-name>
        <param-value>xxxxxxxxxxxxxxxx</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.preauth.password</param-name>
        <param-value>xxxxxxxxxxxxxxxx</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.login.server.module</param-name>
        <param-value>spnego-server</param-value>
    </init-param>



    <init-param>
        <param-name>spnego.prompt.ntlm</param-name>
        <param-value>true</param-value>
    </init-param>

    <init-param>
        <param-name>spnego.allow.delegation</param-name>
        <param-value>true</param-value>
    </init-param>


</filter>

Answer 1

这不是它为什么弹出两次的解释，而是一种在 chrome 中调试它的方法。

浏览到 chrome:net-internals#events，您可以看到 401 身份验证协商。 401 请求和响应不会出现在 chrome 开发工具的网络选项卡中，因此这是您可以获得的唯一线索。

编辑更新 - Chrome 似乎并不总是为digest 发送Authorization header 。要么是因为流水线、auth 缓存错误，要么是 url“继承”授权的启发式方法。

来自 https://groups.google.com/d/msg/chromium-discuss/9ASzOBdBrTQ/wUWFlwFYwaMJ

Since chromium will not pre-emptively send the authorization for inferred protection space, it will keep entering that loop.

[...]

Support for Digest is likely, but a little sketchier, since the digest auth model is broken under pipelining (next nonce is controlled by previous server responses (Authorization-Info).

因为 htdigest 在每次加载页面时都会导致两个登录对话框，所以我切换到基本身份验证，因为我的网站已经使用 HTTPS 来确保安全。 Basic 和 Digest 没有定义需要发送 Authorization token 的 url 以及缓存密码或 token 的时间长度的方案。所以它比 cookie 更慢且更不安全。以后我会尽量避免这种方案。