FormsAuthentication.SetAuthCookie not setting Path

Question

I have a web app can be installed on lots of domains and paths.

So:

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

All separate application instances of the same code.

The problem is that if a client logs in to client1Name.{mySite.com} then visits one of the other sites their browser will send the authentication cookie.

In all cases FormsAuthentication.SetAuthCookie doesn't set either the Path or the Domain.

What I would expect is:

• client1Name.{mySite.com} - Domain = client1Name.{mySite.com} Path = /
• client2Name.{mySite.com} - Domain = client2Name.{mySite.com} Path = /
• demo.{mySite.com}/prospect1Name - Domain = demo.{mySite.com} Path = /prospect1Name
• demo.{mySite.com}/prospect2Name - Domain = demo.{mySite.com} Path = /prospect2Name
• demo.{mySite.com}/prospect3Name - Domain = demo.{mySite.com} Path = /prospect3Name

I can manually override .Net's behaviour to explicitly set these, but I'm not sure why I should need to - sure this should be the default behaviour when setting an authentication cookie or at least an option that can be set without re-writing big chunks of it.

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

If not what is the best way to dynamically read the best Path and Domain? The same code has to run on all sites and I don't want to add a further 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, that seems like a lot of workaround for something FormsAuthentication.SetAuthCookie should be able to do. Is this really the best way?

Answer 1

The cookie is set at the domain level and is static. By default, the FormsAuthentication uses the TLD to set it, in this case {mySite.com}. In order to make it specific, you would have to tell it to use client1Name.{mySite.com}. In doing so, however, you would limit the cookie to that specific subdomain and the subdomain client2Name would no longer be able to access the cookie.

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

I'm not sure what behavior you are attempting to produce using these constraints, but it is unlikely that the cookie is the appropriate tool to do it. Mucking with the domain will limit the effectiveness of your authentication controls (unless that's precisely what you're trying to do).

Answer 2

I've had to do a lot of digging, but is looks like the reason FormsAuthentication.SetAuthCookie doesn't support this is because it shouldn't - IIS should never set paths on authentication cookies, and here's why...

Cookie paths are case-sensitive, so:

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

Are 2 different cookies for the browser - none of them (IE, FX, Safari, Opera or Chrome) will send /PATH's cookie to /path or vice versa.

IIS is case-insensitive, but will always reset the URL to the ASP application name's case.

This means that if the IIS application is called "PATH" and the user goes to http://site/path then they will be redirected to log-on at http://site/PATH/LogOn?ReturnUrl=/path by IIS/ASP.Net

After a successful log-on the user gets redirected back to the ReturnUrl specified, so:

1. User goes to http://site/path
2. Gets sent to http://site/PATH/LogOn?ReturnUrl=/path by IIS
3. Enters log-on details and submits
4. Response sets the cookie to /PATH and the location to /path (as defined by ReturnUrl)
5. Redirected back to http://site/path
6. Browser doesn't recognise /path, it only has a cookie for /PATH and so sends nothing!
7. No cookie sent to application, so it serves a redirect back to http://site/PATH/LogOn?ReturnUrl=/path
8. Go to step 2 and repeat.

This creates a problem for users if they have http://site/path as the URL for the application they will never appear to be able to log-on.

Further to this if they're already logged on to http://site/PATH and get sent a URL, say an email to a http://site/path/resource/id, they will get asked to log on all over again and won't be able to get to the new path.

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