Maintaining Context.User

cjh301 · July 14th, 2003, 06:34 PM

Heres the problem in a nutshell (that I can't crack):

After setting Context.User in page 1, Context.User is lost/reset once the user is redirected to page 2. How do you maintain/keep-alive Context.User across pages?

I've created SiteIdentity and SitePrincipal and am trying to implement it in my Login code.

In Login.asp, once the user is validated against the database this code runs:

Context.User = newUser; <=== SitePrincipal Object
FormsAuthentication.SetAuthCookie( UserName.Text, true )
Response.Redirect("home.aspx");

However, once home.aspx loads, Context.User is a null value.

Am I missing a step here? Followed the provided code to a tee. I had assumed that Context maintained its life across pages much like Session. From what I've read online in order to solve this, you have to reassign Context.User on each page. If thats the case then how does the code from the book work without any additional form autherntication or session code?

Any help would be greatly appreciated.
Thanks,
-Jeff

There was a thread earlier which tocuhed on

pkemman · July 25th, 2003, 07:13 AM

Hi Jeff,

I had the same problem when I tried to build my own implementation of ThePhile. What I found was that visual studio sets the authentication mode to "Windows" in the webconfig file. If we want our code to work we have to change that to "Forms" as we are using FormsAuthentication. I've pasted the entry as it is in the downloaded code. Hope this helps you out.

Kirby

<authentication mode="Forms">
        <forms name="ThePhile" path="/" loginUrl="/ThePhile/Modules/Users/Login.aspx"
            protection="All" timeout="30">
        </forms>
    </authentication>

justin_dago · March 22nd, 2004, 04:36 PM

cjh301,

the key is a combination of the above user and a snippet of code in the Page base:

Code:

    if (Context.User.Identity.IsAuthenticated) 
    {
                if (!(Context.User is PhilePrincipal))
                {
                    // ASP.NET's regular forms authentication picked up our cookie, but we
                    // haven't replaced the default context user with our own. Let's do that
                    // now. We know that the previous context.user.identity.name is the e-mail
                    // address (because we forced it to be as such in the login.aspx page)                
                    PhilePrincipal newUser = new PhilePrincipal( Context.User.Identity.Name );
                    Context.User = newUser;
                }
    }

the outer if tests for authentication, if this is false the redirect from url set in Web.config should kick you back to the login page.

organicglenn · March 25th, 2004, 07:12 PM

I'm wondering, too...
should Context.User be maintaining its state between pages, because my project(unmodified VB sample) is not, either?
Auth Mode = Forms in web.config, and all auth. setting are same as mentioned above.
So after the initial cookie is set, for every page view TypeOf Context.User is GenericPrincipal, and triggers several calls to the DB to populate the SitePrincipal object and set Context.User = SitePrincipal instead. Is this wrong, or simply the nature of stateless page requests??? If so, that's a lot of hits to the DB for every single page view!
Lil' help?

richw32001 · March 27th, 2004, 11:16 PM

I hadn't thought about it before, but that does seem like a lot of hits on the database everytime a page is loaded.

Hopefully you could factor out some of those hits and move them to session variables instead. I haven't really looked at it closely enough to tell if this would cause problems, but you have to consider the implications this has on using the Context-User/Principal-Identity pattern for authentication.

In general you have to determine how to store state so it can be restored quickly and remain small enough that it doesn't consume too many server resources.

Here's a technique I like.

Store state in session variables with properties wrapped around them. Make the properties responsible for detecting that session has expired and load themselves as necessary. This also has the effect of supporting "lazy updating", since if the property is never read then it will never need to be loaded. You can usually reduce the state that has to survive session expiration to a single key that you can store in a cookie. This key is used to restore the properties that dies when the session does.

You don't want to overdo it with the session variables because whatever you use is multiplied by the number of users currently active.

You also don't want to store a lot in cookies, ViewState or hidden fields because it has to go across the wire everytime.

In general, reduce the state you absolutely require to a single key that you can store in a cookie. For state that you need every single time, store it in "session" properties that persist between pages by reloading themselves as necessary. For state that is too large or not necessarily needed, use class member properties initialized to some invalid value that tells the property to load itself if it's ever needed. This avoids loading the same data twice within one page invocation.

- Rich

organicglenn · March 30th, 2004, 02:45 AM

I gotta admit, I didn't follow all those techniques, but I wonder...
do you think that the SitePrincipal stored in Context.User should or should not persist between page requests? Unfortunately, it seems correct that the data doesn't persist, because nothing does except Session variables.
If not, then a bit of string data in a cookie sounds more attractive to me than 3 DB calls just to load the SitePrincipal data for every single page viewed. Although, then the roles/permissions in the cookie may be out of sync with the DB, which is unacceptable.

bschaldon · March 30th, 2004, 04:50 AM

I quickly realised that querying the db every page was not supportable, and stored the Identity data in the Session cache in the Login code.
Context.Session["UserInfo"] = principal.Identity ;

brian