We're building a brand new version of the site, and we'd love to hear your ideas
Members
Technology Zones
IBM Learning Center
Articles
Hosted By
Info
|
[2234] When Session Variables Go Bad
Last post 01-14-2004 9:52 AM by arshad3108. 14 replies.
-
01-01-1999 12:00 AM
|
|
Advertisement
|
|
-
-
-
-
-
-
-
-
-
-
-
-
LACanadian


- Joined on 03-12-2002

- Points 475
|
Whenever I have created a high-traffic, browser-neutral site, I have maintained session information stored in a database. In other words, when a user logs into the site, they are assigned a 32-character identifier. This identifier travels with them as they move from page to page either on the URL or in a hidden field in a form. As they hit a page, I take the identifier and validate it against the session table. At the same time, I can check it against a LastTimeUsed field to see if too much time has passed and a LastPageUsed field to ensure that people aren't jumping into the middle of a process (both are potential signs of hacking). The other benefit is that I can build a log containing the details of the path my users are taking as they move through the web site, something quite useful if you ever need to do a usability analysis.
Does this take longer than storing state information in a session variable? Undoubtably. But a properly configured table, combined with connection pooling keeps the performance impact to a minimum. Not to mention that I can always throw more horsepower at the problem, if necessary. The web sites that I create are designed to be scalable both at the web server level (through load balancing) and at the database level. So if the activity on the web site warrented it, I would have no problem dedicating a database server to just handling the session processing.
Ultimately, I don't think that there is anything inherantly evil with using session variables. In many cases, their ease of use is too appealing to ignore. As someone else mentioned in this thread, my real purpose was to address some questions that I had been asked about session variables, especially when they are used to store ADO connection objects <<shudder>.
|
|
-
-
MarioF


- Joined on 09-04-2002

- Points 5
|
Quote:[1]Posted by Nigorr on 27 Apr 2002 02:53 AM[/1]
So what should we all be using instead. If we can't use cookies, because essientially seesion things use cookies how are you suppose to keep track of users being logged in? I guess you could tack a field on the user that says they are logged in or not but what if they change computer?? and haven't logged out of the other computer??
I Would like to know, what you suggest to use instead of Seesions.
It's difficult to maintain session state without session variables. Solutions there are. Some scripted and some 3rd party tools. Also PHP and ColdFusion have their own methods. But the bottom line is that the "cookies are evil" biscuit talk is nothing more than politics. You should inform your users that your are using cookies and what for. Nowadays browsers give you the ability to have cookies disabled for some sites and enabled for others. All the user has to do is to add your site to the "cookie-safe" list. If some paranoid user still doesn't want your site on his list (or his list is empty and he likes it that way) you should only be ready to accept it and script your site so that he can at least use whatever minimal services you can offer. If even that is not possible... well, that's his and your loss. But the world still turns and it's not the end of it.
Mind you, it's still possible to use session variables even without cookies on the client side. You just have to pass the sessionID on the url and have your scripts coded so they can use it that way. However, this brings some security issues as some guy over the user shoulder may read his session ID and hack into it on a computer next room.
Mario Figueiredo
|
|
-
-
Page 1 of 1 (15 items)
|
Search
Code Samples
New Members
|