14

I got the vibe using session variable is sort of looked down upon in ASP.NET MVC.

Once a user logs in, I would like to retain the user's userId so that I do not have to query it all the time etc.

What is the most efficient way to do that in ASP.NET MVC?

TPR
  • 2,567
  • 10
  • 41
  • 65

4 Answers4

19

I have seen similar questions pop up once in a while and I can't figure out where this "vibe" is coming from. This is what Session is specifically designed for - for storing session-related information. There's absolutely nothing wrong with using Session to store a user id or similar information.

Marek Karbarz
  • 28,956
  • 6
  • 53
  • 73
  • 2
    The vibe is from people incorrectly using Session as Authentication which is exactly what progtick is doing. – John Farrell Feb 15 '10 at 07:14
  • 1
    I thought that the Membership/Profile provider handled all this for you, which its usage is encouraged by Microsoft. They even include an example on the sample app. – Raúl Roa Feb 15 '10 at 13:40
8

You got the right vibe. It is just not necessary in many scenarios. Session state can be easily lost and is often misused for handling logged in user (setting that user is logged in is done by setting Session["IsLoggedIn"] = true or by checking Session["User"] != null, suddenly Session disappears and user is logged out), when forms authentication should be used. Here you can read about forms authentication and storing additional data with it:

Forms Authentication Configuration and Advanced Topics

If you still want to use session, it is good to create wrapper to make it more testable and get rid of strings in code:

Wrapper for ASP.NET Session

Community
  • 1
  • 1
LukLed
  • 31,452
  • 17
  • 82
  • 107
  • Wouldn't you use forms auth and then store the username, etc, in the session? – Joe Phillips Feb 15 '10 at 02:06
  • 1
    @d03boy: Username is stored in forms authentication cookie by default. You can add user's id. If you lose session (and it can happen in many situations, for example when someone changes web.config), you have your data in safe place and don't have to rebuild it. OK, you can use session, but remember that it can be lost when user is logged in. – LukLed Feb 15 '10 at 02:24
2

Sessions are meant to be used for stateful user interaction - a shopping cart comes to mind. They are looked down upon because they are painful to test and tend to force serialization logic into the controller. If you just want to minimize queries, you should use caching.

EDIT: Tutorials for HttpContext.Cache are surprisingly hard to come by. Steven Sanderson has ~4 Pages in Pro ASP.net MVC Framework (Apress 2009) p. 530-534.

Caching in asp.net-mvc might give you some hints too.

Community
  • 1
  • 1
Thomasz
  • 233
  • 2
  • 8
0

Session state. Shouldn't use it when it's not appropriate. But nothing else quite works for credentials. Just make sure they are serializable, so that you can push session out of process when you need to.

BnWasteland
  • 2,109
  • 1
  • 18
  • 14
  • 1
    "But nothing else quite works for credentials" What? Like cookies and FormsAuthentication? Cookies are 1000% more stable than Session. – John Farrell Feb 15 '10 at 07:05
  • Why can't you just check for a session and have the user login again if its not available? I don't quite follow why cookies are better. – Joe Phillips Feb 15 '10 at 17:42
  • And I'm not arguing -- I really would like to hear more about this. – Joe Phillips Feb 15 '10 at 17:43
  • Login is usually a data-intensive process. You have to load not only the user, but also their authorization data. In some cases, this is coming out of external systems (AD/LDAP/Web Svc). That's not the kind of data you want to load on every page request. And all of this assumes the use of a cookie. But you probably don't want that data round trpping on every request, either. So, I prefer to put only keys in the cookie. – BnWasteland Feb 16 '10 at 13:58