Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 288
  • Last Modified:

storing variables for a public website

I am used to creating applications for members, but i am now creating a web site that is going to be available to the entire internet.  I am used to using session variabes, but im not so sure i want to go that routre with the public website.  I am thinking about passing variables from page to page using the URL, is this the best way for a public website???
0
DB_Fury
Asked:
DB_Fury
  • 2
  • 2
3 Solutions
 
wls3Commented:
Using querystring parameters can pose security risks.  If, for instance, you pass confidential information in the query string, the url can be altered or the link can be saved and accessed later without properly checking.  Measures can be taken to encode (or better yet encrypt) the query string which will prevent tampering.  If the information passed on the query string is fairly benign, the risks are lower.  However, this approach lowers the bar for even less experienced hackers to wreak havoc if they so intended.
0
 
DB_FuryAuthor Commented:
so do you recommend using session variables then? should i use InProc for the session mode?  I wonder how long i should set the timeout to if i do that?
0
 
JosephEricDavisCommented:
There are multiple ways to persist data from page to page in an application and they all have their good points, their bad points, and their correct places to be used.

Session variables are one way to save data, but you're right, because of the potentially large amount of use on a public website, the use of session variables could potentially bog down your web server.  Especially if session variables are misused and you are plugging things like entire datatable objects and what not into them.

The query string is another way to store information from one page to another, however, any user that knows much of anything about the internet can modify your query string to manipulate your application in ways you might not have intended.  Some people only recommend using query string variables for stuff that you want the user to catch onto and be able to modify or on pages where you would like the user to be able to copy the url and forward it to someone else who could immediately return to the same page.

Another way to persist data from page to page is to use cookies.  Cookies are a pretty cool way to store data as they aren't directly in the users face and most people don't know how to go in and modify cookies.  However, some people have cookies turned off in their browsers and many people delete cookies on a regular basis.  so you wouldn't really want to store anything in a cookie that the application depended upon to function normally.  You could store stuff like if a certain expandable menu is open or closed and when you return to the page bring back the state of the expandable menu or something like that.

Using hidden fields and cross page posting is yet another great way of persisting data.
http://csharpdotnetfreak.blogspot.com/2009/08/cross-page-posting-in-aspnet.html

ViewState is also an option
http://www.beansoftware.com/ASP.NET-Tutorials/ViewState-In-ASP.NET.aspx

But when it comes down to it, all of these methods are visible to a skilled web user and that person could in turn cause harm with the exposed information in any of these other methods.  So for all sensitive information, usernames, passwords, etc, you should use session.
0
 
wls3Commented:
Session variables are secure and efficient.  You will need to project potential memory issues by calculating session object space requirements with projections for user load.  These are typically fairly straightforward calculations once you learn what all to take into consideration.  After having looked at all your requirements, fitting your server accordingly will depend on those calculations.  

If your session state calculations indicate that the web server will be paging to disk regularly regardless of how much memory you throw in a machine the InProc option does not really make sense.  Realize, however, that when you shift to other storage mechanisms the complication factor begins to rise.  SQL management/maintenance/security are incorporated which make for new headaches a straight InProc session object will not force you to have to contend with.  

As for the timeout, this can often accurately be determined by a good log review.  How long are users spending on your site?  What is the page depth they navigate?  Some statistical review of your traffic can help frame that determination.  If you have have most users on and off your site in 10 minutes, 20 minutes will cover a large portion of your bell curve.  If, for whatever reason, traffic depths/times indicate you need longer than the default, bump it up.  Some good load testing can help you get a feel for how tweaking these parameters can ideally meet the needs of your application.
0
 
JosephEricDavisCommented:
By the way, Session timeout 'timer' restarts as a user goes from one page to the next. 20 minutes is the default setting in IIS and is generally the best option.  So a user would have to sit inactive without making a request to your web server for 20 minutes before the session would time out.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now