Reputation: 363
Why do we need a 2nd mechanism, next to e.g. The forms authentication mechanism, to keep the state? I have quite a good understanding as to why session tokens are used. I also understand the forms authentication mechanism. What i dont understand is why we need the two.
As the formsauth cookie is unique, we could use this to track the user's state, right? I feel this would be a lot safer: we track the state, and we know the user is authenticated. Ive googled a lot, and often people say that, in asp, it is good practice to link sessionid and authentication token together... That is actually the same as just using one of the two for both, no?
One situation where i can think of where we need anonymous state, is in an application where the user does not necessarily need to log in. But then again, we have anonymous authentication, right?
Upvotes: 1
Views: 746
Reputation: 976
In early days of ASP, session was often used as an auth cookie. While the auth and session cookies overlap in simple cases, there are many situations where they need to be separate.
Upvotes: 1
Reputation: 34543
The session and authentication modules can be swapped out individually. It would add complexity for them to try to detect each other so that they can share a cookie in this one case.
It would also (unexpectedly) link operations together. For example, logging out of the app would cause the session to be deleted. This might be preferred but it would only work this way for a specific combination of modules.
You are free to extend the default modules to share the same cookie if you wish. You might even be able to force them to use the same cookie by changing their settings in the web.config.
Upvotes: 1