Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Maybe I’m missing some fundamentals about this, I just don’t get why Form Authentication is not build in top of Session.
I’ve had some issues with Form Authentication timeout and Session timeout, I understand how to get arround those issues thanks to blog posts like this one.
But why are they separated?
Forms Authentication uses cookies which are common in all applications. Only the currently authenticated username is stored into the cookie. The session on the other hand could store arbitrarily large values as it is stored on the server. You cannot persist arbitrary large data into cookies. The session state has lots of problems. For example if you are running in a web farm you need to ensure that you are using an out-of-process session persistence instead of the default InProc so that all nodes of your web farm could share the same session data. Personally I never use sessions in my applications. The very first thing I do is to ensure that I disable all session state in my web.config:
This way I am sure that no developer working on my projects would ever do the mistake of using ASP.NET sessions. They turn web applications which are intended to be stateless into stateful.
With cookies you do not have such problems. You could throw as many nodes you want to your web farm to face increasing user load without ever worrying about any state on the server.