Will the static public variables in my app get shared with other users in the same app?

For reasons I would rather not discuss, I need to create a custom authentication system for my app. I was just reviewing the system and am having some doubts if my solution is thread safe. My goal was to create a solution that would allow my app to authenticate a user one time and that users authentication info would be shared by all master pages, pages, classes, user controls, etc that are used. (But not share the same info between users)

Here is my setup:

PageHttpModule.cs - this is added to the web.config as a httpModule.

public class PageHttpModule : IHttpModule
{
    public void Init(HttpApplication app)
    {
        app.AuthenticateRequest += new EventHandler(OnAuthenticateRequest);
    }

    public void OnAuthenticateRequest(Object s, EventArgs e)
    {
         CurrentUser.Initialize();
    }

    public void Dispose() { }
}

CurrentUser.cs

public static class CurrentUser
{
  public static bool IsAuthenticated { get; private set; }
  public static string Email {get; set;}
  public static string RealName {get; set;
  public static string UserId {get; set;}

    public static void Initialize()
    {
        CurrentUser.AuthenticateUser();
    }


    Note: this is a scaled down version of my authentication code.开发者_如何学编程

    public static void AuthenticateUser()
    {
        UserAuthentication user = new UserAuthentication();
        user.AuthenticateUser();

        if (user.IsAuthenticated)
        {
            CurrentUser.IsAuthenticated = true;
            CurrentUser.UserId = user.UserId;
            CurrentUser.Email = user.Email;
            CurrentUser.RealName = user.RealName;
        }
     }
}

UserAuthentication.cs

public class UserAuthentication
{

    public string Email { get; set; }
    public string RealName { get; set; }
    public string UserId { get; set; }
    public bool IsAuthenticated { get; private set; }

    public UserAuthentication()
    {
        IsAuthenticated = false;
        Email = String.Empty;
        RealName = String.Empty;
        UserId = String.Empty;
    }

    public void AuthenticateUser()
    {

        //do some logic here.. if the user is ok then 
        IsAuthenticated = true
        Email = address from db
        UserId = userid from db;
        Realname = name from db;
   }
}

I have tested between 3 different browsers and it seems to work fine, but I am still learning and don't want to make a huge mistake.

If my logic is totally wrong, then how should I do it so I dont have to put user lookups on every page directly?

No, this is not thread-safe. For instances of the application living in separate processes or AppDomains, this will be just fine. But if your ASP.NET server is going to serve multiple requests at once using threading, you are going to have some very bad side effects if two people try to use the application at the same time.

In the Init method, the HttpApplication parameter is described as:

An HttpApplication that provides access to the methods, properties, and events common to all application objects within an ASP.NET application

The key here is that there is one PageHttpModule for the lifetime of the app, and all static objects that exist in the lifetime of the app will share those variables.

BUT... the lifetime of CurrentUser is only within the scope of the OnAuthenticateRequest event, unless some other reference keeps the object alive. If it were a PageHttpModule member-level variable, you'd have issues that you would have noticed immediately. In your situation, however, you'll work fine so long as you don't get more than one simultaneously-processed OnAuthenticateRequest call.

The answer to your question is no, you're not guaranteed to be thread-safe. If two authentication requests come in simultaneously, you're not guaranteed to have one event complete before the other begins, in which case the second user can appear authenticated, when it's really the first user that was logged on.

Update
I think part of the problem is coming from a misunderstanding of AuthenticateRequest... By the time this event is called, the user has already been authenticated by either Windows or Forms authentication... you're just getting notified that it's happened. In fact, the property User.Identity.IsAuthenticated has already been set (I believe this event fires even if the user fails authentication, but I won't swear to that without double-checking).

If I understand what you are after, you're really trying to write your own custom membership provider. If you take this approach, you will have all the benefits of the built-in authentication... all of the standard properties related to authentication will be set and accessible, and will be isolated to a user's session in the manner you want.

Writing a custom provider is not a small feat, but it is doable, and you should be able to reuse a lot of the logic and code you're currently using for your classes.

Trying to completely re-write the authentication mechanism would be jumping through painful, complicated hoops.

Some links:
http://www.devx.com/asp/Article/29256/0/page/3
http://www.codeproject.com/KB/aspnet/WSSecurityProvider.aspx
http://msdn.microsoft.com/en-us/library/f1kyba5e%28v=VS.90%29.aspx

The properties you must implement may look daunting, but unless you need a specific functionality (such as ResetPassword), you can simply throw a NotImplementedException. Code only what you'll use.

Why not just do it the way microsoft recommends?

http://msdn.microsoft.com/en-us/library/9wff0kyh.aspx

I've done custom authentication this way and it works fine.

Here is another link which should prove useful:

Link

What you have done with IHttpModule seems like a good path to tackle this kind of issue. One of the purposes of the http module as stated by microsoft is to enable for any kind of special authentication. When http module intializes it uses the same instance for new requests. Since you dont have any global variables I am not so sure how to address your thread safe question. It seems like you are onlu reading some data out, so please elaborate!