CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Best way to handle "session" specific user data in a CSLA MVC app?

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 5 Replies | 3 Followers

    Top 100 Contributor
    67 Posts
    Dane posted on Fri, Apr 5 2013 4:17 PM

    I make fairly heavy use of the user's Id value in my application. In the Silverlight and Windows UI Csla.ApplicationContext.User.Identity is of my custom identity type after authentication but, of course, in MVC it resolves simply to an IIdentity object. Is the best approach to persisting something like a user Id to utilize a Session or is there some better approach that CSLA itself helps with?

    Thanks

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts
    Verified by Dane

    I discuss various alternatives in the 'Expert 2008 Business Objects' book and in the 'Using CSLA 4' ebook series.

    Because the web server doesn't remember anything between requests, you have to recreate or re-obtain the principal/identity at the start of each page request.

    In and of itself that's not terribly hard - there's an event in global.asax for this purpose.

    The trick is figuring out the optimal way to recreate or re-obtain the identity data. Common options include:

    • Reload from the database
    • Stash in Session
    • Store in a cookie (if small enough - but usually this isn't workable)
    • Store in a distributed in-memory cache (Velocity, memcached, etc.)

     

    Rocky

    All Replies

    Top 10 Contributor
    9,475 Posts
    Verified by Dane

    I discuss various alternatives in the 'Expert 2008 Business Objects' book and in the 'Using CSLA 4' ebook series.

    Because the web server doesn't remember anything between requests, you have to recreate or re-obtain the principal/identity at the start of each page request.

    In and of itself that's not terribly hard - there's an event in global.asax for this purpose.

    The trick is figuring out the optimal way to recreate or re-obtain the identity data. Common options include:

    • Reload from the database
    • Stash in Session
    • Store in a cookie (if small enough - but usually this isn't workable)
    • Store in a distributed in-memory cache (Velocity, memcached, etc.)

     

    Rocky

    Top 100 Contributor
    67 Posts
    Dane replied on Mon, Apr 8 2013 10:42 AM

    I ended up going with the cookie. I really just needed the UserId to persist and that's plenty small enough.

    Top 10 Contributor
    9,475 Posts

    Ahh, if _all_ you need is the user id (user name) then you don't need to do any work yourself, because Forms Authentication will do it for you. ASP.NET forms authn _already_ creates an encrypted cookie with the username.

    That cookie is used to automatically create a very basic principal/identity on each postback - so you have easy access to the username.

    Rocky

    Top 10 Contributor
    718 Posts

    Not just that, but the forms auth ticket gets encrypted in the forms auth cookie; if you're just storing a user name in a cookie in plain text that seems like a problem if you're using it to pass as authentication.

    Top 100 Contributor
    67 Posts
    Dane replied on Mon, Apr 8 2013 2:45 PM

    No, user name is being stored in the ticket which is being encrypted and then stored in a cookie. I just needed both the user name and the user Id values which was easily accomplished with the UserData field on the ticket.

    Page 1 of 1 (6 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems