摘要式身份验证在 IE8、Firefox 和 Chrome 上不起作用

发布于 2024-08-19 19:00:14 字数 176 浏览 10 评论 0原文

我有一个需要摘要身份验证的网站,当我使用 IE8 浏览它时,即使密码正确,它也会给我 401。 Firefox 和 Chrome 工作正常。我用 Fiddler 检查了授权标头,一切似乎都很好。你能给我关于这个问题的任何提示吗?

ps 另外,我在 C# 中实现摘要身份验证时确实遇到了同样的问题,我不知道这两者是否相关。

I have a website with digest authentication required and when I browse it with IE8, it gives me 401 even the password is correct. Firefox and Chrome works correctly. I checked the authorization headers with Fiddler, everything seems fine. Can you give me any hints on the problem?

p.s. Additionally I do have the same problem with implementing digest authentication in C#, I don't know these two are related.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

温柔一刀 2024-08-26 19:00:14

我遇到了这个问题,这是网上唯一提到的。在摘要式访问身份验证中,事件发生的顺序是。

  1. 在 /url 401 上获取
  2. 使用 WWW-Authenticate 标头
    这会在浏览器上弹出登录对话框。输入您的凭据后。
  3. 获取 /url 以及授权标头。
  4. 200 OK(如果一切顺利)。

这对于 Firefox 和 Chrome 来说工作得很好,但对于 IE8 来说却不能完全工作。

我的意思是,如果我在服务器上的虚拟位置上执行 GET,它会起作用,但当我在静态文件上执行 GET 时,它不起作用。对于静态文件,系统一次又一次地提示我登录。

使用嗅探器后,我发现在请求虚拟位置时,事件顺序如上所述发生,但是当我请求静态文件时,顺序如下:

  1. GET on /url
  2. 401 with a WWW-Authenticate header
    这会在浏览器上弹出登录对话框。输入您的凭据后。
  3. 获取 /url(不带授权标头)
  4. 401 未授权。

基本上,当它是静态文件时,它会获取用户名和密码,但从未在授权标头中发送它。服务器未收到此标头,以 401 响应,再次提示登录。

为了让 IE8 正常工作,你必须欺骗它,让它认为这不是一个静态文件,而是一个虚拟位置。对我来说,这很容易,因为我可以访问服务器的源代码。如果您无权访问它,我真的不知道该怎么做。

如果您请求虚拟位置。
1. GET /虚拟位置
2. 带有 WWW-Authenticate 标头的 401 看起来类似于

WWW-Authenticate: Digest Realm=" [电子邮件受保护]"、domain="127.0.0.1:80"、qop="auth"、nonce="9001cd8a528157344c6373810637d030"、opaque=""、algorithm="MD5"、stale="FALSE

" opapue 参数是一个空字符串。

另一方面,如果您请求静态文件
1. 获取/静态文件.txt
2. 带有 WWW-Authenticate 标头的 401 看起来类似于

WWW-Authenticate: Digest Realm=" [电子邮件受保护]"、domain="127.0.0.1:80"、qop="auth"、nonce="81bd1ca10ed6314570b7362484f0fd31"、opaque="0-1c5-4f7f4c1e"、algorithm="MD5"、过时="FALSE"

这里不透明参数是一个非空字符串。

因此,如果您确保 opaque 参数始终为空字符串,IE8 会将其视为虚拟位置,并且请求将正常通过。由于我可以访问服务器的代码,所以我能够做到这一点。

希望这有任何帮助。

问候,
萨蒂亚·西杜

I was facing this problem and this was the only mention of it on the net. In Digest Access Authentication the sequence of events that take place is.

  1. GET on /url
  2. 401 with a WWW-Authenticate header
    This pops up the login dialog on your browser. After you enter your credentials.
  3. GET on /url along with the Authorization header.
  4. 200 OK (If everything goes well).

This works fine for Firefox and Chrome but was not working fully for IE8.

By fully I mean, that if I did a GET on a virtual location on the server it worked, but it did not work when I did a GET on a static file. In the case for a static file I was prompted for a login again and again.

After using a sniffer I found out that in the case of requesting a virtual location the sequence of events happened as mentioned above, but when I requested a static file the sequence was as follows:

  1. GET on /url
  2. 401 with a WWW-Authenticate header
    This pops up the login dialog on your browser. After you enter your credentials.
  3. GET on /url (WITHOUT THE Authorization header)
  4. 401 Un-Authorized.

Basically when it was a static file, it took the username and password but never sent it across in the Authorization header. Server not getting this header responded with 401 which again prompted the login.

To make IE8 work properly you have to fool it in thinking that this is not a static file, but is a virtual location. For me, it was easy as I had access the server's source code. I really don't know how to do it, if you don't have access to it.

If you have requested a virtual location.
1. GET /virtual_location
2. 401 with WWW-Authenticate header which will look something like

WWW-Authenticate: Digest realm="[email protected]", domain="127.0.0.1:80", qop="auth", nonce="9001cd8a528157344c6373810637d030", opaque="", algorithm="MD5", stale="FALSE"

Notice the opapue parameter is an empty string.

On the other hand if you requested a static-file
1. GET /staticfile.txt
2. 401 with WWW-Authenticate header which will look something like

WWW-Authenticate: Digest realm="[email protected]", domain="127.0.0.1:80", qop="auth", nonce="81bd1ca10ed6314570b7362484f0fd31", opaque="0-1c5-4f7f4c1e", algorithm="MD5", stale="FALSE"

Here the opaque parameter is a non empty string.

Hence, if you an ensure that the opaque parameter is always an empty string, IE8 will consider it as a virtual location and the request will go through normally. Since I had access to the the server's code I was able to do this.

Hope this is of any help.

Regards,
Satya Sidhu

梦年海沫深 2024-08-26 19:00:14

我也有同样的问题。就我而言,我需要使用“<目录/>”中的指令对整个站点进行摘要身份验证。或“<位置/>”。无论哪种方式都适用于 Mac、PC 和 iOS 上的 Firefox 和 Safari。不幸的是,IE8 似乎在这方面遇到了麻烦。在尝试了其他一些更改之后,我终于发现,如果我只需要在子目录上进行身份验证(例如“”),并将我的内容移动到受保护的目录中,IE8 就会开始工作。我来回了几次,只改变了这个属性,以确认这是关键的区别。

顺便说一句,值得注意的是,tcpdump 显示 IE8 甚至没有尝试发送摘要身份验证。它显示了身份验证对话框,获取了我的用户名和密码,然后发送了一个没有身份验证信息的普通 GET 请求。

您正在保护整个内容树吗?

我不确定为什么 IE8(并且只有 IE8)关心这种区别,但这就是我发现的。

在寻找问题的解决方案时,您的提及似乎是相关的,而我在网上找不到任何答案。这让我相信,要么没有人尝试以这种方式配置摘要式身份验证,要么大多数人只是放弃并使用 Firefox(或其他一些非 MS 浏览器)

I had the same problem. In my case, I was requiring digest authentication for my entire site, using directives in either "<Directory />" or "<Location />". Either way works for Firefox and Safari on Mac, PC, and iOS. Unfortunately, IE8 seems to have trouble with this. After trying several other changes, I finally found that if I only require authentication on a subdirectory (e.g. "<Location /private>"), and move my content into the protected directory, IE8 started working. I went back and forth a few times, changing only this attribute, to confirm that this is the critical difference.

Incidentally, it's worth noting that a tcpdump showed that IE8 wasn't even trying to send a digest authentication. It presented the auth dialog box, took my username and password, then sent a normal GET request with no authentication info.

Are (were) you protecting the entire content tree?

I'm not sure why IE8 (and only IE8) cares about this distinction, but this is what I found.

In searching for a solution to the problem, yours was the only mention that seemed relevant, and I could find no answer posted on the net. This leads me to believe that either no one tries to configure Digest authentication in this way, or most people just give up and use Firefox (or some other non-MS browser)

缪败 2024-08-26 19:00:14

哇,我肯定也有同样的问题。我有两个虚拟主机,都使用摘要身份验证。在一个网站上,我试图保护整个网站(即),并且它可以在我尝试过的所有浏览器中工作,除了 IE8。在另一个站点上,我只保护一个子目录,这在 IE8 中工作得很好。

Wow, I'm definitely having the same problem. I have two virtual hosts, both using digest authentication. On one site I am trying to protect the entire site (i.e. ) and it works in all browsers I have tried except IE8. On the other site, I'm only protecting a subdirectory, and that works fine in IE8.

寻找一个思念的角度 2024-08-26 19:00:14

我遇到了同样的问题,并尝试对整个虚拟主机使用摘要身份验证。但以下配置在IE上不起作用。

<Location />
    AuthType Digest
    AuthName "Login"
    AuthDigestDomain /
    AuthUserFile /path/to/.htdigest
    Require valid-user
</Location>

http://lists.centos.org/pipermail/centos/ 中的解决方法2013-January/131225.html 效果很好:

ErrorDocument 401 "some random text"

更好的解决方案是排除通常位于 /error/ 的 apache 错误页面。*

e.g.
Alias /error/ "/usr/share/apache2/error/"

以下配置对我来说效果很好(另请参阅 https://bz.apache.org/bugzilla/show_bug.cgi?id=10932#c5):

<LocationMatch "^/(?!error/)">
    AuthType Digest
    AuthName "Login"
    AuthDigestDomain /
    AuthUserFile /path/to/.htdigest
    Require valid-user
</LocationMatch>

I had the same problem and tried to use the digest authentication for the whole vhost. But the following configuration did not work on IE.

<Location />
    AuthType Digest
    AuthName "Login"
    AuthDigestDomain /
    AuthUserFile /path/to/.htdigest
    Require valid-user
</Location>

The workaround in http://lists.centos.org/pipermail/centos/2013-January/131225.html worked well:

ErrorDocument 401 "some random text"

A better solution is to exclude the apache error pages that are normally located at /error/.*

e.g.
Alias /error/ "/usr/share/apache2/error/"

The following configuration worked well for me (see also https://bz.apache.org/bugzilla/show_bug.cgi?id=10932#c5):

<LocationMatch "^/(?!error/)">
    AuthType Digest
    AuthName "Login"
    AuthDigestDomain /
    AuthUserFile /path/to/.htdigest
    Require valid-user
</LocationMatch>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文