Firefox 在 IIS6 上启用摘要式身份验证的情况下，在每个 HTTP 请求上都要求提供用户名/密码
我最近在我为公司在 ASP.NET 中创建的 Intranet 网站/应用程序上启用了摘要式身份验证。
我这样做的原因是因为 Windows 身份验证似乎只适用于某些用户，而不适用于其他用户。我无法弄清楚为什么，而且我对 IIS 的了解也不够，无法尝试跟踪该问题。经过一番尝试和错误后，我发现摘要身份验证似乎给了我我想要的行为。即：仅允许在域中拥有有效帐户的用户使用其凭据登录网站。
现在的问题是，Firefox (3+) 似乎要求用户对发送到服务器的每个 HTTP 请求进行身份验证。在 Internet Explorer (6+) 或 Chrome 中似乎不会发生这种情况。
我尝试寻找解决方案，但总是陷入死胡同。我会找到有关该问题的讨论，并且每个发布的解决方案都会导致死链接......或者它位于专家交换上，而我无权查看解决方案。
这个问题似乎与（根据我所读到的）不同浏览器发送身份验证标头的方式以及 IIS 解释它们的方式有关。我不确定我能做些什么来改变这一点？我发现的解决方案之一提到编写一个 ISAPI 过滤器来解决这个问题，但是当然，完成的过滤器的链接已损坏，我不知道如何自己制作一个。
我尝试在 about:config 中弄乱 NTLM 和其他与身份验证相关的字符串，以尝试强制 Firefox 信任我的服务器，但这似乎也不起作用。
从我读过的其他一些来源来看，如果我切换回 Windows 身份验证，一切似乎都应该有效，但随后我又回到了第一个方面，身份验证仅适用于某些用户，并且不是其他人。
任一问题的解决方案都适合我，但我对 Windows 身份验证问题的信息很少。如果有人可以指导我跟踪问题，我也很乐意发布更多信息。
以下是我发现的讨论似乎相同问题的 URL。 （抱歉，我无法将它们全部链接，否则它不会让我发布）
- support.mozilla.com/tiki-view_forum_thread.php?locale=pt-BR&forumId=1&comments_parentId=346851
- www.experts-exchange .com/Software/Internet_Email/Web_Browsers/Mozilla/Q_24427378.htmlchannel9.msdn.com/
- forums/ TechOff/168006
- -Twin-bugs-in-IIS-IE-unfair-competitive-advantage-EDIT-SOLVED /www.derkeiler。 com/Newsgroups/microsoft.public.inetserver.iis.security/2006-03/msg00141.html
I've recently enabled Digest Authentication on an intranet website/application I am creating for my company in ASP.NET.
The reason I have done so is because Windows Authentication seemed to only work for some users, and not for others. I could not figure out why nor do I know enough about IIS to try and trace the issue. After some trial and error, I found that digest authentication seemed to give me the behaviour that I wanted. That is: allow only users with a valid account on the domain to log in to the website with their credentials.
The problem now, is that Firefox (3+) seems to ask for the user to authenticate on every HTTP request sent to the server. This does not appear to occur in Internet Explorer (6+) or Chrome.
I've tried searching for solutions but I always arrive at dead-ends. I'll find a discussion about the issue, and every posted solution leads to a dead link...or it's on Experts Exchange and I don't have access to view to solution.
The issue appears to be related (from what I've read) to the way the different browsers send their authentication headers vs how IIS interprets them. I'm not sure what I can do to change this though? One of the solutions I had found mentioned writing an ISAPI filter to fix this, but of course the link to the finished filter was broken and I have no idea how to go about making one myself.
I've tried messing with the NTLM and other auth related strings in about:config to try and force Firefox to trust my server but that doesn't seem to work either.
From a few other sources I've read, it appears that everything should work if I switch back to Windows Authentication, but then I'm back at square one where the authentication would work only for some users and not others.
A solution for either problem would work for me, but I have very little information for the Windows Authentication issue. If someone could guide me through tracing the problem I'd gladly post more information for it as well.
Here are the URLs I've found discussing what seems like the same problem. (Sorry I couldn't make them all links, it wouldn't let me post otherwise)
- support.mozilla.com/tiki-view_forum_thread.php?locale=pt-BR&forumId=1&comments_parentId=346851
- www.experts-exchange.com/Software/Internet_Email/Web_Browsers/Mozilla/Q_24427378.html
- channel9.msdn.com/forums/TechOff/168006-Twin-bugs-in-IIS-IE-unfair-competitive-advantage-EDIT-SOLVED/
- www.derkeiler.com/Newsgroups/microsoft.public.inetserver.iis.security/2006-03/msg00141.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是 FF 中的一个已知错误。 请参阅 Internet Explorer 中的高级摘要身份验证工作原理，但是我们在来自 firefox 的每个 GET 请求上收到多个身份验证提示
IE 6有同样的错误。一个潜在的解决方法是在 IIS6 中重新启用“旧”摘要：
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1d6e22ac-0215-4d12-81e9-c9262c91b797.mspx？ mfr=true
目前，如果服务器发送不透明指令，IE 客户端将返回 RFC 中指定的该指令值。不幸的是，对于来自客户端的后续请求，其中随机数计数增加（计数 2 及以上），不发送不透明指令值。然后，服务器上的身份验证失败，并返回 401 Unauthorized。 IE 客户端现在请求新质询的用户名和密码，并检索文件。
这需要额外的往返，并且每次都会提示用户输入凭据。
RFC 规定必须始终根据客户端的请求发送不透明信息。
IE6 使用的 Digest 实现不符合 RFC (http://www.ietf.org/rfc /rfc2617.txt）。
3.2.2 授权请求头
opaque 和算法字段的值必须是提供的值
在实体的 WWW-Authenticate 响应标头中
要求。
3.3 摘要操作
客户端应该记住用户名、密码、随机数、随机数计数和
与身份验证会话关联的不透明值用于
在未来的请求中构造授权标头
保护空间。
因为客户端要求返回的值是不透明的
在会话期间服务器向其发出的指令，
不透明数据可用于传输身份验证会话状态
信息。
-------- 编辑添加-----
This is a know bug in FF. See Advanced digest authentication works from Internet Explorer however we receive multiple authentication prompts on each GET request from fire fox
IE 6 had the same bug.A potential workaround would be to re-enable "old" Digest in IIS6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1d6e22ac-0215-4d12-81e9-c9262c91b797.mspx?mfr=true
Currently, if the server send an opaque directive, the IE client will return this directive value as specified in the RFC. Unfortunately, for follow-on requests from the client where the nonce count is incremented (count 2 and beyond) the opaque directive value is not sent. This then fails authentication on the server and a 401 Unauthorized is returned. The IE client now requests the username and password for the new challenge and the file is retrieved.
This requires an additional round trip and the user is prompted for credential each time.
The RFC states that the opaque must always be sent on requests from the client.
The Digest implementation that IE6 is using is not RFC compliant (http://www.ietf.org/rfc/rfc2617.txt).
3.2.2 The Authorization Request Header
The values of the opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header for the entity being
requested.
3.3 Digest Operation
A client should remember the username, password, nonce, nonce count and
opaque values associated with an authentication session to use to
construct the Authorization header in future requests within that
protection space.
Because the client is required to return the value of the opaque
directive given to it by the server for the duration of a session,
the opaque data may be used to transport authentication session state
information.
-------- Edit addition -----