Application loses authentication when performing redirect to a virtual directory

Question

I have the following setup: http://www.example.com/dir1/ and http://www.example.com/dir2/

Each virtual directory is configured on IIS6.0 as an application with own AppPool.

When redirecting authenticated user from dir1 to dir2 using response.redirect I lose authentication information for the user and the user is being redirected to the login page. This issue was not coming up with each app (dir1 and dir2) were configured under subdomain, ex: http://dir1.example.com and http://dir2.example.com.

I have resolved the issue by adding a machine key to the machine.config file.

Can someone explain to me why it's not working on a http://www.example.com/dir1 configuration?

Answer 1

I don't know ASP , but my guess would be that you're not specifying a path for the session cookie you're using, so the path setting will default to the path the cookie is being set in, /dir1 and /dir2, respectively.

When using subdomains, you probably used example.com as the main cookie domain, so it was accessible to both subdomains = no problem.

You should be able to find this out by examining the session cookie in your browser (e.g. in the "Cookies" tab in Firefox's Web Developer Toolbar).

If I'm correct, you will need to specify / as the path for the session cookie somewhere.

I don't know at which point to fine-tune that, but maybe it points you into the right direction.

Answer 2

I regularly configure applications this way. There are a few places you can go astray.

1. Each web.config must have an exact duplicate of a common machineKey section. E.G. generate one section and paste it into all web.configs that you want to share FormsTickets with.

2. Each MembershipProvider (and Roles/Profiles etc) element must share the same applicationName attribute. By default this is '/' so unless you have manually changed it there should be not problem.

3. All providers in all applications must share a common connection string to a common aspnetdb instance.

4. If you have tried any of these steps individually or incrementally it is likely that the DB is in an inconsistent state. Ensure that each of these requirements is satisfied and start with a fresh database.

If you follow these steps you should have no problems. This is a fairly common and straight forward use case.

Let me know if you have any more questions.