1

i've a question regarding handling of user logon while porting an application to MVC:

  • in the "old" WebForm days, developers simply used the SessionState object to set a user to logged-on, by -for example- simply putting the userobject into the SessionState (and this userobject holds simple properties like name/lastlogon/etc.)

  • this stuff worked very well for us, and i've seen lots of applications doing it that way

  • yes, i know there is this MembershipProvide-thingy, but i've never used it

Now, in MVC, everybody tells me that "using SessionStat for this is bad" and "apps built that way are flawed in design" and that "there are tons of security risks" and so on.

I've used this method because it worked for the app very reliable, it was simple to implement and it covered all stuff we need.

(Sure, there is the thing with recycling web worker process and emptying the session - but thats not a problem in our case, since the app runs for each country on a dedicated machine)

I've read tutorials, telling me to put that stuff in the DB and -attention- doing a request to the DB to check if the user is logged in, per EACH request? But: Under no circumstances, this is a doable way since i want to keep DB requests on a minimum.

So my question is:

A) whats wrong using this way also in the new MVC app?

B) whats the best way to handle this scenario in a newly built MVC app?

Regarding the session-in-DB-idea: instead of doing this, i'd rater setup an additional service, like a "session-manager" thats get query over the network, but such simple requests should not go to the DB - isn't that a good idea?

Any idea, hint /etc. is highly appreciated since this scenario is really confusing me :-X

johngrinder
  • 422
  • 4
  • 14
  • 1
    Use [Membership](http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx) and Forms/Windows Authentication in any Web Forms or MVC application. It's the official MS recommended way of handling users and authentication. – jrummell Mar 20 '13 at 14:51
  • The user would get an additional cookie, right? Second: Where & how does it store the stuff, plus what does it do if i need the userobject to carry around more objects in the future? – johngrinder Mar 20 '13 at 15:11
  • Regarding membership-provider "usefulness": in this SO thread http://stackoverflow.com/questions/440568/why-should-i-use-asp-net-membership-security-model/ one of the MS-devs himself said "little to no benefit with the included controls" ? – johngrinder Mar 20 '13 at 15:34
  • You're welcome to roll your own, but you will lose many of the built in security features. – jrummell Mar 20 '13 at 15:43
  • That is one of the things that i don't understand either: currently, the site uses SHA-clientside encryption (via JS) to hash the password, our server will nerver now it. If username+password is correct, session object Session["UserObject"] is filled and for this session object is checked on each page reload of in-portal-pages --> this solution does work fast & efficient. What are your mentioned security features, that we will miss? – johngrinder Mar 20 '13 at 16:34
  • You'll have to read up on Membership can compare it to your own solution. – jrummell Mar 20 '13 at 16:39

1 Answers1

2

A)

A fundamental principal of the asp.net mvc framework is that its stateless. Data is passed around using http requests and sent to the views in viewmodels. Web forms tried to maintain state with viewstate etc thats why you would have seen the logged in user in session approach. Thats not to say session shouldnt be used completely in asp.net mvc, there are some circumstances when it can be useful. Like maintaining a 3 step form process that has to be persisted on the last step. But generally we already have a recommended way to handle the user logins, and thats forms authentication

B)

For accessing the user object, you can create a custom identity implementing the IPrincipal interface and add the required user fields you need. Then set the custom identity in a global filter and access it in your action results. Regarding not wanting to query the database for every request, why dont you just call it for the initial request, then cache the result until the user is updated where you then can reload the object and set it in the custom identity again.

Community
  • 1
  • 1
gdp
  • 8,032
  • 10
  • 42
  • 63
  • To **A)** A user has to be identified across a logged in session - if not, you couldn't surf on Facebook or by on Amazon; they need to "identify" a user on each request, they need to know to which of their server sessions a current request belongs - then, their design is also flawed if you bring up the stateless-argument? To **B)** all this identity/principal stuff - how does it store to which user/account a request belongs? Even that system must store the stuff *anywhere* in the servers memory/worker process - or do i miss something? How does it handle the question "user-logged-in?" – johngrinder Mar 20 '13 at 19:42
  • Really, currently i think i do not understand anything at all, while the app is already live in two countries. :-( the stuff really really confuses me - maybe its not an implementation issue but more a software-philosophic question... – johngrinder Mar 20 '13 at 19:43
  • To identify the user across a logged in session, you can set a cookie using FormsAuthentication.SetAuthCookie, this will login the user populating the User.Identity.Name (user username) property after a redirect. You can then use this value inside the cookie to query your db between requests and populate the custom identity (with additional user info you need). – gdp Mar 21 '13 at 10:01
  • Is it possible to cash the users identity within that object? (i mean the "custom identity", not the cookie ;-) ) - as said, querying the DB on each request just to show, for example, the username and the birthday is far too much? So there must an option to cache it? In SessionState, we could simply add the complete complete userobject (yes, i this would involve unboxing/deserialisation on each request, but that sounds better to me than a complete roundtrip to the DB for that trivial info) – johngrinder Mar 21 '13 at 15:32
  • 1
    Your free to cache the user results from the db however you like, System.Runtime or System.Web caches are possibilities that i would look into using. So you save the username in the cookie on authentication, use that to query your db and load the results into the cache, on each request you can set the custom identity with the user object from the cache. – gdp Mar 21 '13 at 16:54