How to remove unwanted WWW-Authenticate headers

Question

From the MVC application, I am preparing an iCal authentication subscription after answering this SO question:

Serving an iCalendar file in ASPNET MVC with authentication

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

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

However, on the shared server of my web host, authentication does not work for both Calendar and Outlook. That is, they both ask me about the user and password after unsuccessful (correct) ones.

EDIT: If I point the browser to the calendar URL, it will also complete authentication.

EDIT: Retrieve authentication in Weirder-Firefox and retrieve the iCal file. Check Safari, Chrome and IE.

If I point the cursor to the calendar URL with the same credentials, I succeed (that is, I get the desired iCal file). And, of course, the same credentials can be used to enter the MVC application.

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

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

At the moment, only Firefox is responding with basic authorization, which succeeds.

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

IE responds with Negotiate, which doesn't work

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

Who adds the other two and how can I make him stop? Here in 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

Answer 1

Haha, the answer lay in the IIS configuration.

I asked my host administrators to disable other authentications that broke everything except the iCal feed.

Now they have returned the pair again, and the MVC site is working, as well as the authentication calendar ... whew! A very, very big smile.

Here the IIS configuration ended:

 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 am happy.

Answer 2

 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM 

used by Windows authentication. Since you have finally enabled anonymous authentication, all WWW-Authenticate headers are not displayed.

Answer 3

A simple way:

If you want this “ X-Powered-By-Plesk ” header to be removed from EACH NEW created domains, you can create a default web.config file in the “Default template template” folder of httpdocs.

This default website template is usually located in the folder "C: \ inetpub \ vhosts.skel \ 0 \ httpdocs". This web.config file will be used by default when creating a new website.

 <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <httpProtocol> <customHeaders> <remove name="X-Powered-By-Plesk" /> </customHeaders> </httpProtocol> </system.webServer> </configuration> 

TIP 1: this method can be removed to remove the unwanted custom header (so as not to tell too bad about the bad guys about your server):

 <remove name="X-Powered-By"/> <remove name="X-Powered-By-Plesk"/> <remove name="X-AspNet-Version"/> <remove name="X-AspNetMvc-Version"/> 

TIP 2: If you want to remove any Dynamic Header (for example, the famous "server" ), you will need to work with outgoing rights :

  <configuration> <system.webServer> <rewrite> <outboundRules> <rule name="StripHeader_Server" patternSyntax="Wildcard"> <match serverVariable="RESPONSE_SERVER" pattern="*"/> <action type="Rewrite" value=""></action> </rule> <rule name="StripHeader_ETag"> <match serverVariable="RESPONSE_ETag" pattern=".+" /> <action type="Rewrite" value="" /> </rule> </outboundRules> </rewrite> </system.webServer> </configuration> 

TIP 3: Alternatively, you can use this default web.config file to set all the configuration options that you want to use for each new website (for example: to define a default list of documents for your sites, as described in this article Plesk help: https://support.plesk.com/hc/en-us/articles/213364049-How-to-configure-global-default-document-settings-in-Parallels-Plesk )

Answer 4

As a belated response to this, you can also handle this by creating your own message handler.

The message handler will inherit from the DelegatingHandler and should be added to its MessageHandlers in the HttpConfiguration

It might look like this:

 public class EnsureNoAuthenticationHeaderHandler : DelegatingHandler { async protected override Task<HttpResponseMessage> SendAsync( HttpRequestMessage request, CancellationToken cancellationToken ) { var response = await base.SendAsync( request, cancellationToken ); if ( response.StatusCode == System.Net.HttpStatusCode.Unauthorized ) { response.Headers.Remove( "WWW-Authenticate" ); } return response; } } 

And then register it in HttpConfiguration something like this:

 private void Register( HttpConfiguration configuration ) { configuration.MessageHandlers.Add( new EnsureNoAuthenticationHeaderHandler() ); } 

Which you would probably name from your global configuration. A message handler can also be attached to a route directly, so if you do not want it to be available everywhere, just look at the related article on MSDN for more explanation.