5

When I make a site that requires registration and login, for something quick without a lot of requirements I'll use Membership with [Authorize] attributes and whatnot. Works well for what it does. But now I'm wanting something more. Basically I'm developing a site using ASP.NET MVC EF CodeFirst and want to create a User entity to persist to the DB that holds much more information. Such information required when registering would have additional properties such as FirstName, LastName, Gender, Country, etc...

I've tried reading over implementing a custom MembershipProvider and MembershipUser, etc... I've gone so far but it's just not coming together the way I want in the end. Now when I develop a site in PHP or, other times in ASP.NET, I'll just create my User class and give him all the properties needed for the registration page and just push it to the DB. Then when I login I just grab the username or email and password and just create a session variable indicating whether the user is authorized or not.

Is this ok to do? I just don't understand why this whole Membership thing is so much more complicated than it appears to have to be so I feel like I'm missing the point of it all. Also, I notice in an ASP.NET MVC web app that when you're authenticated it writes out this line....

FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false);

What is the difference between that and...

Session["username"] = model.UserName
Shane LeBlanc
  • 2,633
  • 13
  • 42
  • 74

1 Answers1

2

Rather than go the route of a membership provider (I personally don't like it and find it much to heavy for the applications I work with) have you considered simply creating a custom IPrinicipal / IIdentity object for your application and extending them with the properties you want from your "User" object?

Rather than get into the specifics there are already some great resources on SO that cover this concept: ASP.NET MVC - Set custom IIdentity or IPrincipal

In regards to your question, Session["username"] is simply a session cookie. You lose all benefits of FormsAuthentication. For example with forms auth if the user requests a page that requires authenticated access and that user has not previously logged on to the site, then the user is redirected to a configured logon page with forms auth.

With Session["username"] you would need to manually roll every aspect of authentication. I would strong recommend NOT doing this.

Community
  • 1
  • 1
Jesse
  • 8,223
  • 6
  • 49
  • 81
  • 1
    Well I guess I'm off to do even more reading... Seems every time I think I've decided on something, something else is suggested and I never know which way to go to ensure optimal performance in the long run... Thanks for your answer. – Shane LeBlanc Jun 13 '12 at 02:56
  • One thing I forgot to mention is that using FormsAuthentication and setting the current IIdentity and IPrincipal will allow you to access the "Current User" on each request (similar to your php comment). For example to get the current "username" you would simply use User.Identity.Name within your controller. – Jesse Jun 13 '12 at 03:16