passing variables from one page to another

[knobby2k]

Hey people,

 

I know this is going back to basics but i'm just learning and want to make sure I do it all correctly.

 

I want to pass variable's from one page to another. Now currently say I wanted to hold the users age and email address from his record in the database from page A and pass it to page B for it to be displayed back to him I would store each in their own session variable (so for the purpose of the explanation session_user_email=me@email.com and session_user_age=18.

 

On page B I would then call the session and store it in a variable then destroy the session.

 

Just out of curiosity is the the best way to pass the data? or should i use another method?

 

i've read about session hijacking and i'm now worried about holding personal data within a session so i'm wondering what other people do??

 

Cheers

[JasonLewis]

Using sessions to allow data to be available on subsequent pageviews is fine. In fact most people use sessions for that purpose.

[knobby2k]

Thanks,

 

I'm not leaving myself vulnerable or my users vulnerable by storing a few items of personal data in a session??

 

much appreciated

 

Pete

[xyph]

Unless you want this information to persist during and ENTIRE session, DON'T USE SESSIONS.

 

Sessions aren't good at transferring data from one page to the next, use the query string for that. If you want to keep important static data throughout an entire session, use sessions. Things like user information and access levels are good. Shopping cart information is okay, but still better kept in a DB imo. Things like last page visited, form information, etc are generally not good.

 

There are exceptions to those rules though, and in the event that it makes sense to use sessions (caching search results to save queries through pagination) you should be using a unique token for that request passed through the query string to keep that information attached to that specific request. You wouldn't want a search result in a separate tab messing with the data of a search result in another.

[knobby2k]

Unless you want this information to persist during and ENTIRE session, DON'T USE SESSIONS.

 

Sessions aren't good at transferring data from one page to the next, use the query string for that. If you want to keep important static data throughout an entire session, use sessions. Things like user information and access levels are good. Shopping cart information is okay, but still better kept in a DB imo. Things like last page visited, form information, etc are generally not good.

 

There are exceptions to those rules though, and in the event that it makes sense to use sessions (caching search results to save queries through pagination) you should be using a unique token for that request passed through the query string to keep that information attached to that specific request. You wouldn't want a search result in a separate tab messing with the data of a search result in another.

 

Thanks,

 

What do you mean 'use the query string'?

 

Cheers

[ManiacDan]

Thanks,

 

I'm not leaving myself vulnerable or my users vulnerable by storing a few items of personal data in a session??

 

much appreciated

 

Pete

Not at all, no.  The session is stored on your server and can only be accessed by a user with the proper cookie.  Sessions are vulnerable to hijacking, but it's generally not a huge concern.  Your site itself will be vulnerable to this sort of attack, the location of the personal data doesn't really matter.  Once your site is big enough to where session hijacking (through something like firesheep) is a problem, you'll know enough to roll your own session handler with built-in security and verification.

 

-Dan

[knobby2k]

Thanks,

 

I'm not leaving myself vulnerable or my users vulnerable by storing a few items of personal data in a session??

 

much appreciated

 

Pete

Not at all, no.  The session is stored on your server and can only be accessed by a user with the proper cookie.  Sessions are vulnerable to hijacking, but it's generally not a huge concern.  Your site itself will be vulnerable to this sort of attack, the location of the personal data doesn't really matter.  Once your site is big enough to where session hijacking (through something like firesheep) is a problem, you'll know enough to roll your own session handler with built-in security and verification.

 

-Dan

 

Cheers Dan, much appreciated

[xyph]

Query string is the part of the URL after the page, and before the anchor.

 

The bold part is the query string

 

domain.com/folder/file.php?this=that&foo=bar#anchor

 

Here's a very in depth read on why sessions are generally a bad idea for anything other than static information. It even goes as far as to say avoid sessions completely

http://00f.net/2011/01/19/thoughts-on-php-sessions/

[knobby2k]

Query string is the part of the URL after the page, and before the anchor.

 

The bold part is the query string

 

domain.com/folder/file.php?this=that&foo=bar#anchor

 

Here's a very in depth read on why sessions are generally a bad idea for anything other than static information. It even goes as far as to say avoid sessions completely

http://00f.net/2011/01/19/thoughts-on-php-sessions/

 

cheers mate i'll have a read through.

 

thanks again

[voip03]

For security purposes, check all variables when they come in, any user can change the GET string and give out of range or erroneous data

 

[ManiacDan]

I disagree with portions of that article posted.  He claims there's no reason to use sessions and talks about using cookies instead.  The problem with that is cookies are limited to 2kb in some browsers and are not at all serial in nature. 

 

You cannot have a shared read-write of cookies between scripts.  Only the most recent request counts, and cookies can easily be overwritten if you rely on them for data storage.

 

Cookies are sent along with every web request, so if you store as much data as you can in the cookies you're increasing the size of EVERY request, in both directions. 

 

Cookies can be read by the user and anyone on the same network or who can sniff traffic in the middle (unless encrypted, like it says in the article)

 

Having been a developer on a number of very large websites ("very large" as in 100,000+ hits per second), the concept of server-stored sessions is very powerful, but once you scale beyond a single server you cannot rely on the default PHP session handler, you have to write your own.  I'd never rely on cookies for this, I've always uses memcache or a custom listener that accepted read/write requests in parallel from multiple running scripts. 

 

-Dan

 

[xyph]

I disagree with portions of that article posted.  He claims there's no reason to use sessions and talks about using cookies instead.  The problem with that is cookies are limited to 2kb in some browsers and are not at all serial in nature.

 

Of course, but he isn't suggesting using cookies for large amount of data, simply to store a key that references data server-side, or to store basic static data that you may want to display on every page (things like user name, etc.)

 

I think what he's trying to emphasize here is that storing BASIC information like user names in sessions requires a request to the file system or database, depending on your session handler. It's unneeded, and a few extra bytes in the header is better than having to make that transaction.

 

You cannot have a shared read-write of cookies between scripts.  Only the most recent request counts, and cookies can easily be overwritten if you rely on them for data storage.

 

He's not suggesting to store mutable data in the cookies. He's suggesting to break away from the 'one token to control them all' idea that PHP sessions are all about. Instead, use cookies to store keys that reference to that data in a database. You don't want the data in your cookies to change, you want it to persist over multiple stateless requests.

 

Cookies are sent along with every web request, so if you store as much data as you can in the cookies you're increasing the size of EVERY request, in both directions.

 

Again, the idea here is to store only immutable data in the cookie. If it's a lot of data, you're doing it wrong. It should at most be a couple of keys, a few strings, and an HMAC hash of the raw data. This is a very small increase in a request's/response's size.

 

Cookies can be read by the user and anyone on the same network or who can sniff traffic in the middle (unless encrypted, like it says in the article)

 

This is no different than pure PHP sessions. Whether in the query string or a cookie, someone reading the raw headers will be able to hijack the key.

 

Having been a developer on a number of very large websites ("very large" as in 100,000+ hits per second), the concept of server-stored sessions is very powerful, but once you scale beyond a single server you cannot rely on the default PHP session handler, you have to write your own.  I'd never rely on cookies for this, I've always uses memcache or a custom listener that accepted read/write requests in parallel from multiple running scripts. 

 

Of course, sessions have their place. He's more suggesting to dump PHP's session handler altogether (he suggests a few alternatives). If you have mutable data that you may need to access on certain requests give it a unique key, throw the data in a database, and the key in a cookie. If you have a bit of static data you want to persist through page requests, why require the script to pull it from a flat file? Store it in a cookie, and use an HMAC hash of that data to prevent it from being altered. It's no less secure than keeping only a key, and adds a few hundred bytes to a request.

 

The nice part about keeping a key for each group of mutable data you need to store is that you only request THAT data. If you use a session to store shopping cart information, PHP will load that data into memory whether it's needed or not simply by calling session_start();

 

I agree he does go to an extreme, but his points are mostly valid. You add a little bit of extra data into the request to potentially save a little memory/processing on the server side. It's also good to look at the web as stateless rather than stateful, and to design around that principle.

 

TL;DR - He's not saying dump sessions (he comes close, he says 'sessions are overused' in a very awkward way), he's saying they should only be used to store immutable data and that the PHP session handler is bulky and slow at doing that.

 

Looking forward to your response

[knobby2k]

debates like this where you hear one view point against another are perfect for someone learning like me. you hear both sides of an argument and can make a judgement call on what you think is best from peoples advice! keep it up lads.

 

Cheers