00:00
00:00
Newgrounds Background Image Theme

MutantZulu81241 just joined the crew!

We need you on the team, too.

Support Newgrounds and get tons of perks for just $2.99!

Create a Free Account and then..

Become a Supporter!

Sessions or Cookies

1,822 Views | 19 Replies
New Topic Respond to this Topic

Sessions or Cookies 2005-09-09 23:25:41


Yes, the question of the moment, sessions or cookies? I've read many articles on it myself, and unfortunately they are split down the middle. Either one side raves that cookies are the only way to go, or the other insists you have to use sessions

So I thought I'd bring it to my favorite group of programmers. For user log-in and tracking, what's better? sessions or cookies?

My basic knowledge:

sessions cause more strain on the server but are accepted by everyone

cookies, while client-side, are not accepted by all

WHAT'S THE VERDICT?


BBS Signature

Response to Sessions or Cookies 2005-09-10 00:00:55


Personally at the moment I use sessions However you are free to let the user decide.

on an included page you could use

if ( ! // session variables ) {
$_USER = $_COOKIE;
}
else {
$_USER = $_SESSION;
}

and of coorse on the login page (im assuming this is for a user system), you whould set the values to the type the user asked for. and to access any of the values just use $_USER['value']; Ta Da.

Response to Sessions or Cookies 2005-09-10 00:04:01


Personally I think sessions are the best way to go, but still use cookies as a "remember my info" type thing. Where you would store thier userid and pass in a cookie, then check it against the database, and then set the session data using the info from the database that matched up with the cookies


BBS Signature

Response to Sessions or Cookies 2005-09-10 00:30:01


Yeah, you can't go wrong with sessions. They only become very resource intensive if you set the session timeout for a very long time. The longer an unused session takes to time out, the longer the server has to keep track of it. So if you use a normal session timeout, sessions shouldn't be extreamly resource intensive.

Response to Sessions or Cookies 2005-09-10 04:35:55


You can make a custom session storage, using cookies.


Each time someone abuses hittest, God kills a kitten. Please, learn real collision testing.

Response to Sessions or Cookies 2005-09-10 11:45:32


Both. And SQL.

Be safe.


BBS Signature

Response to Sessions or Cookies 2005-09-10 12:23:26


I thought you said it's not open for debate. anyhow, you know where I stand :)

Response to Sessions or Cookies 2005-09-10 12:34:54


I agree with what Craige said. The way my site is setup the user can pick between sessions and cookies depending on which method he/she feels most comfortable and secure with. You shouldn't have to use an if-else or ternary construction each time you want to check, though.

As Craige demonstrated you can set your own SUPERGLOBAL that is included throughout your program and inevitably its faster and much easier to maintain. He gave you a sample code and I can show you what is easiest in my experience.

On my site, I use a SUPERGLOBAL similar to what he (Craige) demonstrated. Here is a sample code, depending on how many session/cookie vars you set you can decide if they're logged in with sessions, cookies, or not logged in at all.

$_TYPE = ( isset($_SESSION['username']) && isset($_SESSION['password']) )
? $_SESSION : $_COOKIE;

If you paste that code into your favorite text editor (php coder, Dreamweaver, etc) and delete the new line before the ? operator it seems to look a lot cleaner.

Anywho, after you decide if they're logged in via cookies or sessions you can run a series of checks (usually with one on-the-fly function) to see if they're actually logged in. Like so:

function is_user() {
if ( !isset($_TYPE['username']) || !isset($_TYPE['password']) ) {
// Not logged in
return false;
}

// Check for their entry in MySQL or other DB (I demonstrate with MySQL)
$sql_check = "SELECT username FROM users WHERE password = '" . addslashes($_TYPE['password']) . "' AND username = '" . addslashes($_TYPE['username']) . "' LIMIT 1";
$get_user = mysql_query($sql_check);

if ( mysql_num_rows($get_user) == 0 ) {
// No record found
return false;
}

return true;

} // End function

That would be a very simple function to test if the user is logged in, of course with anything in scripting/programming the only limits are your imagination, wants, needs, and desires.

If you have any other questions let me know. I'd say use both as many will tell you. Some users hate having to type their information in over and over to log back into a site and in turn it makes them not want to login as much. On the other hand, people who like sessions don't want to have to press LOGOUT each time they quit browsing the site as to prevent a younger sibling (or anyone else) from wrongfully accessing their settings.

A good website lets the users choose as much as possible (within the parameters of site security and server security of course). Just experiment and fall in love with the easy compatibility.


Merkd.com - It Pays to Play

Earn real money by betting and investing; or, sponsor, challenge, compete,

recruit, communicate, network, earn money playing games, and much more.

Response to Sessions or Cookies 2005-09-10 13:22:53


At 9/10/05 12:34 PM, Pilot-Doofy wrote: stuff

Yeah, I think I'll have to end up going with both :/ Just make it a choice when they initially sign up then? and something they can change later

And a question about the code...
Why are you storing their password and username and rechecking it every page (or are you) ? Can't I just set $_USER['valid'] when they log in and just check that for every page after?


BBS Signature

Response to Sessions or Cookies 2005-09-10 13:47:42


At 9/10/05 01:22 PM, Afro_Ninja wrote:
At 9/10/05 12:34 PM, Pilot-Doofy wrote: stuff
Yeah, I think I'll have to end up going with both :/ Just make it a choice when they initially sign up then? and something they can change later

And a question about the code...
Why are you storing their password and username and rechecking it every page (or are you) ? Can't I just set $_USER['valid'] when they log in and just check that for every page after?

because if you just set $_USER['valid'] how woudl you know what user us valid? it could be anyone. you would also have to set $_USER['user_id']. and then that is still insecure because teh user can just change that in the cookie on their computer and come off as an admin.

And as to why it is checked so often with that function, When setting the user's info in cookies(or even sessions). the user can modify that information(ie cookies on there computer). but by checking that all the cookie vars corospond to one row in the database. it ensures that the user hasn't tried to mask them self as an admin or somthing by changing some of the informathon like the user id and the username, but leaving the password. in unsecure coding(like MW's old code), you could change the username (and/or id) in the cookie and apear as whomever you entered because it did not check that all teh data was correct.

Response to Sessions or Cookies 2005-09-11 01:56:49


At 9/10/05 01:22 PM, Afro_Ninja wrote: $_USER['valid']

A function that runs one MySQL query is relative fast compared to other multi-dimensional functions you will (hopefully) right in the near future. As Craige said, how would you know the information stored in $_USER['valid'] is actually VALID? You wouldn't.

The server sets the variable "valid" in the users cookie or session headers and BAM, the user changes it to 1 (assuming you're using a true-false stance) and automatically they're "logged in".

It'd be great if it were that easy but people would quickly take advantage of your trust.


Merkd.com - It Pays to Play

Earn real money by betting and investing; or, sponsor, challenge, compete,

recruit, communicate, network, earn money playing games, and much more.

Response to Sessions or Cookies 2005-09-11 02:13:57


ok here's a question I have after reading this
http://uk.php.net/ma..ession.use-trans-sid

"A visitor accessing your web site is assigned an unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL. "

if the session id is stored as a cookie then why not just use cookies to begin with?

and as for tacking the session id onto the end of urls, they say this:

"URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example. "


BBS Signature

Response to Sessions or Cookies 2005-09-11 02:30:20


Well, there's a simple answer to the "sessions with cookies" questions. When the browser is closed the cookie storing the session id is erased. Since PHP doesn't have javascript functionality you can't use an onClose type event.

Also, I forgot and read over the part where you said "let them choose when they signup" and stuff.

Well, why not just have a box as NG and my site do? If a user signs up wanting to use cookies and later wants to use sessions he/she would have to do this:
Login
Edit session/cookie storing
Logout
Login

You could do all of those or check/uncheck a little box which handles it all for you. That's the simplest method I've found and everyone else uses it as well. Any site with choice of sessions/cookies (or nearly all of them) will use the checkbox rather than a login feature.


Merkd.com - It Pays to Play

Earn real money by betting and investing; or, sponsor, challenge, compete,

recruit, communicate, network, earn money playing games, and much more.

Response to Sessions or Cookies 2005-09-11 02:35:49


At 9/11/05 02:30 AM, Pilot-Doofy wrote: Well, there's a simple answer to the "sessions with cookies" questions. When the browser is closed the cookie storing the session id is erased. Since PHP doesn't have javascript functionality you can't use an onClose type event.

well, what I was thinking was this...

people say to use sessions because some people have cookies disabled. Well, if someone disables cookies then the session can't be made regardless, since the session id is on a cookie...right?

or am I looking at this wrong?


BBS Signature

Response to Sessions or Cookies 2005-09-11 02:44:47


At 9/11/05 02:35 AM, Afro_Ninja wrote: or am I looking at this wrong?

Right, if they don't allow cookies. However, appending the session id to the URL is pretty old and outdated. Few sites if any still use it. The main sites that use it are those who are using old versions of freeware such as phpBB, etc.

If you're completely concerned about compability with people who don't allow cookies you are sacraficing comfort for those who do. You could always check to see if the cookie was set by attempting to retrieve it and if it isn't you could append the session id to the URL but that sequence is also redundant.

I suggest just use sessions AND cookies and don't worry about those who have cookies disabled because they probably won't be logging in to begin with.


Merkd.com - It Pays to Play

Earn real money by betting and investing; or, sponsor, challenge, compete,

recruit, communicate, network, earn money playing games, and much more.

Response to Sessions or Cookies 2005-09-11 16:35:48


Well, my only real concern was people that didn't have cookies enabled. But if I don't need to worry about them then what advantage do sessions have over cookies?


BBS Signature

Response to Sessions or Cookies 2005-09-11 19:08:18


The whole point in using sessions is to facilitate access to pages that require users to be logged in for people who DON'T have cookies enabled on their browser (as well as those that do). The method of tacking a session id onto the end of the url is not deprecated, that's there for a reason.

Sessions are NOT stored in the cookie. They're stored on the webserver, typically in /tmp for linux based systems. They're little files that sit there for the duration of max session lifetime and perhaps longer, depending on garbage collection.

The Session cookie points to this file that's in the temp directory. When a user closes a window that's been using sessions, the cookie on their machine disappears, but the file on the server does not - when that disappears is all down to how you have the garbage cleanup on session files set up on your server.

As for phpbb - it uses its own session management, rather than the default php sessions. That sort of application is created with the intention of being deployed immediately on a wide variety of setups and is set to run on everything from very small to very large websites, which will have more than one webserver.

Running php sessions on that sort of setup is not a wise choice, for obvious reasons: the session would be stored in the /tmp directory of each of the webservers, rather than in a global place. So, if the user were to come to the site and lands on server 1 of 5, logs in, then clicks another page, they might land on server 5 - at which point, their session doesn't exist, since they're on another machine.

There are a couple of workarounds that I can think of in that scenario:

1. Have the sessions read/write from one central place, rather than each of the temp directories on the webservers in the cluster. Not typically a wise idea if your site is highly trafficed...
2. Have the sessions read/write from a database. Aside from having the same problems in case 1, with the exception that each of the pages on your site are going to have to make a hit to the database (if of course, you're catering for the non-cookie crowd)... Which is complete over kill if that's ALL it's doing (rather than making further queries of some significance).

At the end of the day, if you're gearing your site up so that it's only friendly to people who have cookies enabled, then use cookies to store their information and save un-necessary disk reads/writes.

Response to Sessions or Cookies 2005-09-11 21:05:24


At 9/11/05 07:08 PM, liljim wrote: Sessions are NOT stored in the cookie. They're stored on the webserver

Wouldn't that make Sessions safer than cookies because you can't alter them on your machine.

Response to Sessions or Cookies 2005-09-11 21:10:31


At 9/11/05 09:05 PM, Wasson wrote:
At 9/11/05 07:08 PM, liljim wrote: Sessions are NOT stored in the cookie. They're stored on the webserver
Wouldn't that make Sessions safer than cookies because you can't alter them on your machine.

Why? If you alter the cookies on your machine and that allows you to access certain parts of scripts that you shouldn't be accessing, you have to ask yourself whether your script is secure enough in the first place.

Response to Sessions or Cookies 2005-09-12 01:50:21


You can always encrypt the cookies, but xor is a waste of time, go with something tested.
<?php
class cookies extends encryption inherits sessionstorage {
function open{
start_output_buffering();
return true;}
function read{
return $this->decrypt($_COOKIES['session']);
}
function write($sdata) {
return @setcookie('session',$this->encrypt($sdata
));
}
function close{
return output_and_close_output_buffering();
}
}?>


Each time someone abuses hittest, God kills a kitten. Please, learn real collision testing.