What things should be saved in SESSION and what should not be?_问答_开发者

I give one example why this question appears in my head: Lets say i create class 'PDOstart' which extends PDO class. On class 'PDOstart' all variables needed for PDO is defined on private section (like host, user, password and ect). So it makes very easy to use PDO class like:

$con = new PDOstart();
$con->query("SELECT ... ");

Because on my webpage I use only one DB I b开发者_运维问答egin thinking why not add PDOstart object into SESSION? like: $_SESSION['db'] = $con; ? So i don't need on every page do "new PODstart". But I'm not sure that will be good idea...

Is there anything what i should avoid add to $_SESSION (for security or performance reason)?

user id so that every time the page loads you know what use is browsing, meta data such as timespan from page changes (Bot Detect), Local information, User template selection. anything that's required for that session really.

As you stated $con let me explain something.

There are several variable types in php and the main ones are:

strings
boolean's
integer's
objects
arrays
resources

Now you can store all of them into the sessions apart from resources, as there such things as file handles, connections to external entities there only open for the time it takes the page to be processed by PHP, then there closed.

the others are ok as there stored in the memory and are static as such, they will not change unless you programmatically change them.

The main entites you should store in the session are

GUID: So that you can track what user is logged in.
Flash Data: So if your doing a redirect you will be able to show a error message on the other page.
Browser Data, so that you can compare that the browser that is currently browsing is the same as the last, this way you can kill the session fro security.

Things like Database Data such as User Rows should not be stored in the session and you should create a separate cache mechanism to do this for you.

You can store your PDOstart class in the session, as long as you keep this in mind:

When you do $_SESSION['key'] = $obj, you actually serialize the object (assuming default php session handler, that happens when the data is flushed).
When you do this to a 'resource', such as a database connection, there is every likelihood the connection will not persist.
To workaround such cases, php has the __sleep and __wakeup magic methods

I would assume your PDOstart class will ensure connection to PDO on both __construct and __wakeup, doubling the complexity.

However, there's another reason for not doing it that way: the session might go away at any moment, so you shouldn't really rely on any information being there. Surely you can place safeguards, which would re-initialize everything, but that again is adding unneeded complexity.

There's no golden rule (at least that I'm aware of) that explicitly states you should keep as little info as possible in your sessions, but it seems to be a fairly common approach. I'd keep a user id and probably an access token. There's not much stopping you to do it otherwise tho.

As for security, this kind of use shouldn't really matter, as long as the session as a whole is secure. They never truly are, but it's a whole different topic.

Short answer: good things to store - user id, bad things to store - everything else.

Some complement to the good response of RobertPitt you should really add an autoloader if you start storing objects in the session.If the class of your object is not available you'll get a standard broken objet if you do not have an autoload mecanism for class loading.

Then, depending on how your session are stored you should be careful of the size they take. let's say you store it on a very fast drive or on a memcached service, you do not need to worry too much about the fact that this file will be read for every request of your user. If you have slow IO on your drive be careful. Now if you store your session in a database you may care about the insert/update/delete rythm on the session table, some databases (think about MySQL) are not very god at handling an high write load on one table.

In term of security you do not have to worry too much about session storage as it is on the server. At least if you (the admin) use disk storage you should ensure that all handled application are not using the same directory for session storage, if not the weaker application will define you security level for sessions.