通过

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

  • Anonymous
    September 18, 2008
    Static methods should be OK, right?

  • Anonymous
    September 18, 2008
    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

  • Anonymous
    September 18, 2008
    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?

  • Anonymous
    September 18, 2008
    Absolutely rite Torn.....we faced that kinna prblm in past because of static global variables in a multiple server environment.

  • Anonymous
    September 18, 2008
    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.

  • Anonymous
    September 18, 2008
    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

  • Anonymous
    September 18, 2008
    The scope of a static variable is limited to an Application Domain.

  • Anonymous
    September 18, 2008
    So what would the solution be to persist data for only the current user? Store it in the session?

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

  • Anonymous
    September 19, 2008
    bobh, Yes, if the data is private to each user, session is a good place to store it.

  • Anonymous
    September 19, 2008
    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.

  • Anonymous
    September 19, 2008
    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