如何删除不需要的WWW-Authenticate标头 [英] How to remove unwanted WWW-Authenticate headers

问题描述

在MVC应用程序中，我正在根据此SO问题的答案采购带有身份验证的iCal订阅：

在ASPNET MVC中提供带身份验证的iCalendar文件

使用DDay.iCal库从数据库中的事件动态创建iCal流。

此解决方案在本地开发服务器上正常工作：两个OSX日历和Outlook可以订阅并从应用程序接收更新。

但是，在我的Web主机的共享服务器上，日历和Outlook的身份验证都失败。也就是说，他们都一直在问我用户和用户。 （正确）失败后的密码。

编辑：如果我将浏览器指向日历网址，它也无法通过身份验证。

编辑：获取weirder-Firefox进行身份验证并获取iCal文件。 Safari，Chrome和IE验证失败。

如果我使用相同的凭据将curl指向日历URL，我就成功了（即我获得了所需的iCal文件）。当然，相同的凭据可用于登录MVC应用程序。

编辑 - 我想我知道发生了什么，但我不知道如何要解决这个问题。在我的 OnAuthorization（）中，我只添加 WWW-Authentication Basic 但是使用Fiddler我可以看到三种类型的身份验证是提供：

  HTTP / 1.1 401未经授权
 WWW-Authenticate：Basic realm =Secure Calendar
 WWW-Authenticate：Negotiate 
 WWW-Authenticate：NTLM 
 ... etc ... 
  

此时只有Firefox使用基本授权进行响应，后者成功。

  GET<<>>> HTTP / 1.1 
 ... 
授权：基本<<编码凭证>> 
  

IE以Negotiate回应，失败

  GET<<>>> HTTP / 1.1 
 ... 
授权谈判<<编码的东西>> 
  

谁正在添加其他两个，我该如何让它停止？以下是服务器响应的详细信息：

  HTTP / 1.1 401未经授权
缓存控制：私有
 Transfer-Encoding：chunked 
 Content-Type：text / html 
 Server：Microsoft-IIS / 7.5 
 X-AspNetMvc-Version：3.0 
 WWW-Authenticate：Basic realm =安全日历
 X-AspNet-Version：4.0.30319 
 WWW-Authenticate：Negotiate 
 WWW-Authenticate：NTLM 
 X-Powered-By：ASP.NET 
 X-Powered-By-Plesk：PleskWin 
日期：2012年10月23日星期二13:27:48 GMT 
  

谢谢，
Eric

解决方案

哈哈，答案在于IIS配置。

我要求我所在主机的管理员关闭其他身份验证，这会破坏除iCal Feed之外的所有内容。

<现在他们又重新开启了一对，MVC网站的工作方式与日历提要一样有效......哇！非常非常大的微笑。

这是我们最终得到的IIS配置：

 名称状态响应类型
启用匿名身份验证
禁用ASP.NET模拟
基本身份验证禁用HTTP 401质询
摘要身份验证已禁用HTTP 401质询
表单身份验证已启用HTTP 302登录/重定向
启用Windows身份验证HTTP 401质询
  

我不确定为什么这个有用 - 或者还有什么可能会破坏 - 但今天我很高兴。

From an MVC app, I'm sourcing an iCal subscription with authentication following the answer to this SO question:

Serving an iCalendar file in ASPNET MVC with authentication

The iCal stream is being created dynamically from events in the DB using the DDay.iCal library.

This solution works fine on the local development server: both OSX Calendar and Outlook can subscribe to and receive updates from the app.

However, on the shared server at my web host, the authentication fails for both Calendar and Outlook. That is, they both keep asking me for user & password after the (correct) ones fail.

EDIT: If I point a browser at the calendar URL it also fails authentication.

EDIT: Getting weirder—Firefox authenticates and gets the iCal file. Safari, Chrome and IE fail authentication.

If I point curl at the calendar URL with the same credentials I'm successful (i.e. I get the desired iCal file). And, of course, the same credentials can be used to login to the MVC app.

EDIT — I think I know what's going on, but I don't know how to fix it. In my OnAuthorization() I add only WWW-Authentication Basic but with Fiddler I can see that three types of authentication are offered:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Secure Calendar"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
... etc ...

At this point only Firefox responds with Basic Authorization, which succeeds.

GET <<URL>> HTTP/1.1
...
Authorization: Basic <<encoded credentials>>

IE responds with Negotiate, which fails

GET <<URL>> HTTP/1.1
...
Authorization Negotiate <<encoded stuff>>

Who is adding the other two and how can I make it stop? Here's more detail from the server response:

HTTP/1.1 401 Unauthorized
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
WWW-Authenticate: Basic realm="Secure Calendar"
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-Powered-By-Plesk: PleskWin
Date: Tue, 23 Oct 2012 13:27:48 GMT

Thanks, Eric

解决方案

Ha ha, the answer lay in IIS configuration.

I asked the admins at my host to turn off the other authentications, which broke everything but the iCal feed.

Now they've turned a couple back on again and the MVC site works as well as the calendar feed with authentication... whew! Very, very big smile.

Here's the IIS configuration we ended up with:

Name                        Status         Response Type
Anonymous Authentication    Enabled
ASP.NET Impersonation       Disabled
Basic Authentication        Disabled       HTTP 401 Challenge
Digest Authentication       Disabled       HTTP 401 Challenge
Forms Authentication        Enabled        HTTP 302 Login/Redirect
Windows Authentication      Enabled        HTTP 401 Challenge

I'm not sure why this works—or what else might break—but today I'm happy.

这篇关于如何删除不需要的WWW-Authenticate标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！