ASP.NET Tips: Careful Use of Static’s


Not sure how many people realize it, but when you start dealing with multiple users access a system (in this case a web server), you have to be very careful what you store in static’s (global variables).  This is because all the users will have access to this data and so if you create a page, you could allow them to see data that they shouldn’t.

The main place this comes into play is with SQL data.  We recommend that you cache data from the database so you don’t have to query for it on each request.  But if that data is sensitive, then you need to make sure you do not store it in cache or some other global.

Comments (13)

  1. Doctor says:

    Static methods should be OK, right?

  2. Another thing to keep in mind is how often static constructors fire on web applications. I was bitten by that a few days ago.

    http://hectorcorrea.com/blog/Static-constructors-and-ASP.NET-applications.aspx

  3. Nick says:

    Not really sure what you’re trying to say. Declaring something as static does not turn it into a global variable and nobody would ever refer to a global variable as a static becuase they’re obviously not.

    I’m also not sure why you’ve put the apostrophe in "statics"? The static’s what?

  4. Sumit says:

    Absolutely rite Torn…..we faced that kinna prblm in past because of static global variables in a multiple server environment.

  5. tomchris says:

    Nick,

    the ‘ was just cause of spellcheck.  And I didn’t catch it to change it back.  It depends on what you mean by global, but if you mean that other can access that bit of memory, that it is global.  If you mean any part of the application can access it, then you are right, it is not.

  6. Yes this is a good point talk about, last month someone raised a post regarding this in ASP.NET Forums

    http://forums.asp.net/t/1302762.aspx

    thanks for sharing

  7. daveblack says:

    The scope of a static variable is limited to an Application Domain.

  8. bobh says:

    So what would the solution be to persist data for only the current user? Store it in the session?

  9. rtpHarry says:

    If my data layer has static functions such as update and two requests come in at the same time could this potentially cause problems?

  10. tomchris says:

    bobh,

    Yes, if the data is private to each user, session is a good place to store it.

  11. tomchris says:

    rtpHarry,

    No that shouldn’t cause any problems.  The application is meant to handle multiple threads all calling a static function at the same time.  No problem with that.

  12. daveblack says:

    Just to underscore some things (Tom already answered a few):

    1. User-specific values should really be stored in Session.  You could use client-side cookies if there is not any security sensitive info in there (e.g. username, password, etc.).   Also, client-side cookies are limited to 4K in length.  ASP.NET Personalization and WebParts is an option for WebPart kind of things.  If the values are meant only to be held for the life of the ASP.NET page, you could also use Viewstate (again don’t place security-sensitive info here since ViewState is only Base64 Encoded and not encrypted).

    ***<b>As a security note, you should *not* store password in Session or in Cookies in case the Session or Cookie is hijacked (which is trivial to do).</b>***

    2. Application-wide or “shared” values should really be stored in the Cache.  These values can be seen and accessed by anyone in the AppDomain, so be careful not to put sensitive or user-specific values in there.  Another option is to use Application variables.  However, it is recommended to use the Cache.

    3. Initialization of Static variables in Thread-safe in all versions of .NET.  This is why the Singleton Pattern uses static variables for its implementation.

    4. The use of Static Constructors should be carefully considered.  You should use Static Initializers (or inline initialization of a static variable – i.e. inline where it is declared) when possible.  The CLR is able to optimize the performance of types that have not explicitly defined a static constructor.  One case of this is with the use of NGEN.  The biggest difference of use of a static constructor vs. inline static variable initialization is the <b>timing</b> of when each happens.  The majority of the time you shouldn’t, and don’t, care about when your static variables are initialized.  However, if it is of importance, the CLR will initialiaize inline static vars. whenever it wants to.  On the other hand, the firing ofa static constructor is guaranteed to happen right <b>before the first static member is accessed.</b>  Note that *all* static members who are not explicitly initialized inline are initialized once the static constructor fires.  Obviously if you needed to do additional things with a static variable after it has been initialized, you would need to use a static constructor instead of inline initialization.      

    HTH

  13. Raj says:

    Here is a sample webpage that shows the dangers of using static variables in an ASP.Net website without understanding its consequences:

    http://www.aggregatedintelligence.com/Samples/StaticsDemo/default.aspx

    And my explanation:

    http://blog.aggregatedintelligence.com/2009/01/static-variables-and-their-implications.html