Create an scalable ASP.Net MVC web site without using Session

Question

Hi,

I'm working on a Web project using Asp.Net MVC, which I'll have to deploy to a farm environment.

I've read a lot of articles and I'm thinking on disabling completely the SessionState, I think this would make a more robust application, and will save me a couple of headaches (Everything I've read tells me that handling sessions on a farm isn't trivial).

There are some things that I still don't have totally clear with this approach though, the main one being the authentication/authorization process. Basically I'm not sure of how (if?) I can handle user sessions if there's no SessionState enabled on the server. If a user logs into the web site and then tries to access another page, how can I know that the user is already logged in? I know using cookies is insecure, I thought of a mix of cookies with the session Id stored in the DB, but I suppose that if I disable SessionState I won't have access to the session id either.

What's the best approach on this? Is there any recommended book/article you can point me to so I can get this clear?

Thanks a lot for your help

Answer 1

I think use Forms Authentication for this this will be manage your logged in user name and you can also set authorization through this.

http://msdn.microsoft.com/en-us/library/ff647070.aspx

http://msdn.microsoft.com/en-us/library/xdt4thhy.aspx

http://www.codeproject.com/KB/web-security/formsroleauth.aspx

http://www.beansoftware.com/ASP.NET-Tutorials/Forms-Authentication-Active-Directory.aspx

These links are ans of your each question. Through this you can manage role authorization and session

Answer 2

It may be possible that if there are workflows that your application supports that you want to persist over application recycling (cluster node failure) you may be able to ignore the persistent Session complexities completely.

Consider an ecommerce checkout example or a similar multi-step process that requires a lot of state management before completion. The suggestion is to design the model of your application is such a way that during these "steps" the progress of the workslow is persisted to the data store natively though the model. That is, the "workfolow" is not some sort of externality to the main model of your app and as such treated as a "temporary" thing that requires some persistence mechanism like the aspnet Session as opposed to the apps regular data store (database).

For example, rather than storing the checkout object tree (lists of items, orders, etc) in Session, persist it to the database itself. This way not only does that "partially completed checkout" survive node failure or application recycling but additionally, if that user has to go put out an urgent fire in the kitchen or their Windows Update crashes their PC, they can resume when they log in next. :D And: you avoid all that complex distributed session management stuff. Yuk!

I know this answer extends further than just the authentication point that the question actually highlights, but this is good to know and certainly a problem clustered/farm environments place on aspnet apps.

Hanselman on clustered mvc apps: http://www.hanselman.com/blog/LoadBalancingAndASPNET.aspx

Answer 3

FormsAuthentication and the ASP.NET user profile work without SessionState enabled--they run on cookies and database lookups by default.

For shopping cart-type scenarios I'd strongly consider just saving the data in the database and tagging users -- it lets people come back and grab abandoned carts.

What can and will break without the SessionState enabled is MVC's TempData -- it stashes things in the session between pages. But, if you just avoid using it, you are golden.