Custom Principal/HttpContext/Application Context problem.

Custom Principal/HttpContext/Application Context problem.

Old forum URL: forums.lhotka.net/forums/t/1717.aspx


Brent posted on Wednesday, November 08, 2006

We have a recently deployed website that receives a large amount of traffic.  I'll try to describe the problem.

 

UserA logs in which creates the principal object in the application context as in the book.

 

UserB navigates to the login page.  When the page is loading, if I check HttpContext.Current.User, I find UserA with their authenticated Identity.

 

Our application handles sessions a little differently since we use a single sign on system.   Therefore it’s possible that a User is authenticated but that their session has timed out.  In such cases we check Request.IsAuthenticated and if so logout the user and redirect them back to the login page (so login controls, etc can reinitialize).

 

As you might guess, what happens is that UserB will end up in an endless loop of redirects until some user of the application logs out, finally removing the authentication from the HttpContext.Current.User.

 

One thing that we are doing differently from the book is that we don’t user the global.asax to recreate the Principal in the session.  We use an HttpModule instead.

 

Can anyone think of why the principal for UserA is ending up the HttpContext.Current.User for UserB?

 

I’m stretched on this one.  Thanks for you help.

 

skagen00 replied on Wednesday, November 08, 2006

I'm afraid I don't have the answer for you myself but I thought I'd mention that I could have sworn I've seen this brought up somewhat recently. (You might find your answer on a prior post).

Brent replied on Wednesday, November 08, 2006

Before I posted I searched:

Principal ApplicationContext

Principal AppDomain

Custom Principal HttpContext

ApplicationContext HttpContext

and a few others.

I couldn't find a post with this problem.

Brent

RockfordLhotka replied on Wednesday, November 08, 2006

Yes, this was discussed somewhat recently in this thread. The problem, in that case, and probably this one, is the use of some static/Shared field within the context of the web site.

static/Shared fields exist at the AppDomain level - which in ASP.NET means at the virtual root level. Anything you store in such a field is shared across all users of the site, which is often a bad thing.

My guess, based on your description, is that you are doing something with caching and/or a static field as part of your HttpModule or other pre-page processing. As a result you are somehow accidentally "bleeding" user A's data into subsequent page requests.

Brent replied on Wednesday, November 08, 2006

Thanks Rocky.  We had investigated the potential of a static method but didn't find anything.  We have however solved the problem and while it doesn't directly apply to CSLA I thought I would respond with our solution in case someone else runs into the same problem.

As I stated, we use an HttpModule to handle the regeneration of the ApplicationContext.User.  What we were not aware of is that IIS only loads this module one time per appdomain and then runs each applicable request thru the one instance.  I had placed properties on the HttpModule for certain authentication properties to regenerate the User.  If a new user who had no previous authentication cookie came to the login page, these properties were not overridden with those in the user’s cookie.  Therefore, our HttpModule was regenerating the ApplicationContext.User with the last successful logged in user's credentials.

We move the properties into a separate object that is declared and initialized on app_BeginRequest to ensure that each user's credentials are uniquely generated for each request.  That solved the problem.

It was an interesting problem that was difficult to track down because of our rather complex single-sign-on system we use for our enterprise applications but we learned a lot in the process.

Thanks for taking the time to help.

P.S.  We’ve been using CSLA now for about a year and have run into few if any problems.  Thanks!

Copyright (c) Marimer LLC