Does FormsAuthentication.SetAuthCookie not set a path or domain?

Question

I have a web application that can be installed on many domains and paths.

So:

• client1Name. {MySite.com}
• client2Name. {MySite.com}
• demo. {MySite.com} / prospect1Name
• demo. {MySite.com} / prospect2Name
• demo. {MySite.com} / prospect3Name

All individual application instances of the same code.

The problem is if the client is in client1Name. {mySite.com}, then he visits one of the other sites, their browser sends an authentication cookie.

In all cases, FormsAuthentication.SetAuthCookie does not set either Path or Domain .

What would I expect:

• client1Name. {mySite.com} - Domain = client1Name. {mySite.com} Path = /
• client2Name. {mySite.com} - Domain = client2Name. {mySite.com} Path = /
• demo. {mySite.com} / perspective1Name - Domain = demo. {mySite.com} Path = / perspective1Name
• demo. {mySite.com} / perspective2Name - Domain = demo. {mySite.com} Path = / perspective2Name
• demo. {mySite.com} / perspective3Name - Domain = demo. {mySite.com} Path = / perspective3Name

I can manually override .Net behavior to explicitly set them, but I'm not sure why I need it - this should be the default behavior when setting a cookie for authentication, or at least an option that can be set without re writing big pieces.

Am I missing something? Is there a way to make FormsAuthentication.SetAuthCookie set Path and Domain ?

If not the best way to dynamically read the best Path and Domain ? The same code should work on all sites, and I do not want to add an additional configuration key.

Update

Here is my current solution:

 // replacement for FormsAuthentication.SetAuthCookie(user.UserName, false); // as that fails to limit the cookie by domain & path and fails. var cookie = FormsAuthentication.GetAuthCookie(username, false); cookie.HttpOnly = true; cookie.Path = this.Request.ApplicationPath; cookie.Secure = string.Equals("https", this.Request.Url.Scheme, StringComparison.OrdinalIgnoreCase); // the browser will ignore the cookie if there are fewer than two dots // see cookie spec - http://curl.haxx.se/rfc/cookie_spec.html if (this.Request.Url.Host.Split('.').Length > 2) { // by default the domain will be the host, so www.site.com will get site.com // this may be a problem if we have clientA.site.com and clientB.site.com // the following line will force the full domain name cookie.Domain = this.Request.Url.Host; } this.Response.Cookies.Add(cookie); 

However, this seems like a lot of workaround for something that FormsAuthentication.SetAuthCookie should be able to do. Is this really the best way?

Answer 1

I had to dig a lot, but it seems that the reason FormsAuthentication.SetAuthCookie does not support this, because it should not - IIS should never set the paths for authentication cookies, and here's why ...

Cookie paths are case sensitive, therefore:

• http://site/path
• http://site/path

There are two different browser cookies: none of them (IE, FX, Safari, Opera or Chrome) will send /PATH cookies to /PATH or vice versa.

IIS is case insensitive, but the URL will always be reset in the case of an ASP application name.

This means that if the IIS application is called "PATH" and the user goes to http://site/path , they will be redirected to the system login http://site/PATH/LogOn?ReturnUrl=/path using IIS / ASP.Net

After a successful login, the user is redirected back to the specified ReturnUrl like this:

• The user goes to http://site/path
• Gets the message http://site/PATH/LogOn?ReturnUrl=/path using IIS
• Enters login data and sends
• The response sets the cookie to /PATH and the location to /PATH (as determined by ReturnUrl )
• Redirected back to http://site/path
• The browser does not recognize /PATH , it only has a cookie for /PATH and therefore does not send anything!
• There is no cookie sent to the application, so it redirects back to http://site/PATH/LogOn?ReturnUrl=/path
• Go to step 2 and repeat.

This creates a problem for users if they have http://site/path as the URL of an application that they will never be able to log into.

In addition to this, if they have already logged into http://site/path and sent the URL, send an email to http://site/path/resource/id , they will be asked to log in again and will not be able to receive to a new path.

This means that unless you need /PATH and /PATH to be completely different sites (unlikely outside of certain UNIX environments), you should never set the path property to authentication cookies.

Answer 2

The cookie is set at the domain level and is static. By default, FormsAuthentication uses a TLD to install it, in this case {mySite.com} . To make this specific, you would have to tell him to use client1Name.{mySite.com} . However, you would limit the cookie to this particular subdomain, and the client2Name subdomain would no longer be able to access the cookie.

The cookie path limits the subfolder to which the cookie applies. In the case of FormsAuthentication, the default value for the / root is set again. You can manually set it to something else, but again, setting it to /prospect1Name , all other folders will immediately lose access to the cookie.

I'm not sure what kind of behavior you are trying to create using these restrictions, but it is unlikely that a cookie is a suitable tool for this. Dumping with a domain will limit the effectiveness of your authentication tools (if that’s exactly what you are trying to do).