views:

52

answers:

1

Hi,

Just spent the last 3 days exploring membership, iprincipal, identity and other goodies..but something is still not clear. Why it is better to use that incited of simply store a minimize logged in user object in session? it can hold roles, permissions and other custom properties.

to achieve the same thing the asp.net form auth way i would do:

protected void Application_AuthenticateRequest() 
{ 
    HttpCookie cookie = Request.Cookies.Get(FormsAuthentication.FormsCookieName); 
    if (cookie == null) 
        return; 
    bool isPersistent; 
    int webuserid = GetUserId(cookie, out isPersistent); 

    //Lets see if the user exists 
    var webUserRepository = Kernel.Get<IWebUserRepository>(); 

    try 
    { 
        WebUser current = webUserRepository.GetById(webuserid); 

        //Refresh the cookie 
        var formsAuth = Kernel.Get<IFormsAuthService>(); 

        Response.Cookies.Add(formsAuth.GetAuthCookie(current, isPersistent)); 
        Context.User = current; 
    } 
    catch (Exception ex) 
    { 
        //TODO: Logging 
        RemoveAuthCookieAndRedirectToDefaultPage(); 
    } 
} 

private int GetUserId(HttpCookie cookie, out bool isPersistent) 
{ 
    try 
    { 
        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(cookie.Value); 
        isPersistent = ticket.IsPersistent; 
        return int.Parse(ticket.UserData); 
    } 
    catch (Exception ex) 
    { 
        //TODO: Logging 

        RemoveAuthCookieAndRedirectToDefaultPage(); 
        isPersistent = false; 
        return -1; 
    } 
}

So i'll need to query the DB on each authenticated request, when in using session i'll do it only once when the user logs in, i know you can store the roles and other user data in the ticket cookie but i don't think its secure since an attacker can modify the cookie content, move it and more..

so, any one else agrees?

+1  A: 

The default InProc Session state is not durable and will "disappear" whenever your App Pool recycles.

The SqlStore session is durable but then you have an additional load on your db server.

Cookies are the best choice for websites at the moment and that probably won't change for a long time. Cookies are relatively secure and as long as you encrypt cookie content, which .net does by default, you should be ok.

Note: There is a big security flaw in .Net regarding its default encryption methods so when I say secure I mean was secure and probably will be again.

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

jfar
Worth pointing out there are alternatives to the above too, if you're happy to stray off the beaten path a little. Mongo/Memcached can be good out of proc stores for this kind of thing.
Nik
Thanks, but consider the scenario above, does it make sense to keep hitting the DB in every request to get the user obj and assign it to the context?
TomerMiz
Hi, can anyone respond?
TomerMiz
@TomerMiz - "does it make sense to keep hitting the DB in every request to get the user obj and assign it to the context" This is totally dependent on 1. How much time you have to develop. 2. What your expected traffic is. 3. How much $$$ do you have for hardware. 4. Benchmarks and testing to determine your load levels. As far as I can tell you haven't even begun developing anything yet. Wait until you get some traffic and see what makes sense performance wise.
jfar

related questions