Last post Oct 18, 2013 12:37 PM by John_Scanlon
Oct 16, 2013 05:01 PM|John_Scanlon|LINK
I know the difference between static and instance classes. That's my question - I don't understand how code inside a static class.method() like "var currentUser = Membership.GetUser(userName, true)" can work in the method whose signature is "public
static bool ChangePassword(string userName, string currentPassword, string newPassword)" (in WebMatrix.WebData.WebSecurity).
In a busy environment isn't there a danger that users could overwrite each others' data in this routine? My curiosity is not idle - I need to replace WebSecurity in an MVC site with my own security layer because my shop requires all database access go through
stored procedures. I need my own WebSecurity class and I'll use a static class and static methods if I'm sure I won't have data corruption in production. Could someone please explain the execution model that allows this? Are static classes allocated once per
thread which is then isolated to an http request? Thankx...
Oct 16, 2013 05:04 PM|BrockAllen|LINK
Because under the covers it's using HttpContext.Current which is itself a static, but it's implemented (essentially) in terms of thread local storage. This means the static property is different on each thread (which makes sense because each HTTP request
is being processed on different threads).
Oct 17, 2013 09:29 AM|Illeris|LINK
I think you should separate the principle of static data and static methods. I'll focus on web development in the text below.
Every user in a web app will use it's own session in the web app. You can compare this by 1 user, 1 thread. Every thread executes a piece of code that is statically compiled. This code can have variables that are local or static. Code parts (methods, classes)
can be static or not.
A static variable in a webapp will be shared by all users in the application. This means there will be only one instance of it, with one value. All threads access this piece of data. If, by accident, 2 threads access the value at the same time (one read,
one update, or 2 update) you get into trouble. You'll never know what the outcome will be.
If you have a static method, it is like you are sharing one set of instructions for all threads. There is no problem with this, until the moment you access data or variables. If you access variables in the static code, you get the same issue as mentioned
above. However, there is an escape option. You can create static methods that can safely deal with these data conflicts. This means you either use thread synchronization techniques (such as lock, ...), or you avoid using static data in static methods. This
last can be achieved by, in the static method, calling the current session HttpSession.Current. This allows you to access thread local data from within a static method.
This is what happens in your static ChangePassword method:
Oct 17, 2013 04:41 PM|John_Scanlon|LINK
If I understand your answer correctly, what you're saying is that WebSecurity is part of the assembly also containing HttpContext.Current which is invoked with each request. As each request gets a separate copy of this assembly, whatever it is, that's why
these static classes are threadsafe. But unless I can get my "WebSecurity" replacement class added to this assembly, my implementation
won't be threadsafe.
I think that's the info I needed, thanks! I'm marking your answer as correct but please update this topic if my understanding is wrong.
And I wouldn't think this would have any implications for the FormsAuthentication cookies I'm getting from System.Web.Security, but if you can confirm this, that would be helpful. These cookies are handled across separate requests so I would think they have
to use session storage outside the static storage in this assembly.
Oct 17, 2013 04:47 PM|BrockAllen|LINK
Well, if you write a membership provider and it's being used by simple membership, then you will need to ensure in your provider that you are thread safe. But as long as you're not accessing state on your class, then you should be ok. IOW, just use local
variables in your implementation of the various APIs.
As for forms auth cookies, this has nothing to do with session state -- totally unrelated features and they don't rely upon one another to perform their function. I don't know why, but this is a common misconception. Anyway, I am not sure what storage you're
referring to when yuo're talking about forms auth and the cookies. Perhaps this will help:
Oct 18, 2013 12:37 PM|John_Scanlon|LINK
Thanks again Brock!