FormsAuthentication.SetAuthCookie not setting Path or Domain?

Question

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

So:

• client1Name.{mySite.com}
• client2Name.{mySite.com}
<

Answer 1

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.

Answer 2

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).