What is the Proper Usage of $_SESSION in PHP

Question

According to php website , session support in PHP consists of a way to preserve certain data across subsequent accesses. This enables you to build more customized applications and increase the appeal of your web site. A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL. The session support allows you to register arbitrary numbers of variables to be preserved across requests.

Tapping onto the experience of programmers here, I would like to know what are the things that should be stored in $_SESSION and what are the things that should not . Example, is it a good idea to store data in a session to avoid repeated queries on the database?

Answer 1

Store only what you need to maintain state (ID's, small piece of highly used data, etc).

Database results can be cached in an appropriate caching layer (memcached, APC, etc) if performance begins to suffer from query abuse.

I'd avoid storing complex structures in session that are otherwise located in other data storage areas (DB for example). Keep it simple.

Update

Another popular use and one I've used is to store interim data before processing. An example is a multi-page / wizard style form.

Answer 2

I am a beginner php programmer myself but I had a perfect experience using sessions.

1. you can use sessions with any data I think. I used them mainly to transfer users' inputs and queries outputs from a page to another

2. One thing to note, when you use sessions, use them on "one-way" page path. I mean if you have data transferred with sessions from page1 to page2, do not access page2 from any page other than page1, otherwise you will have no session output in page2.

Hope I did not confuse you. I am trying to help a little

Thanks :)

Answer 3

You can indeed avoid database queries by putting data in a session, but only to avoid multiple trips to the database. A system like Drupal, for example, puts the session data in the database, so replacing a single database query with storing data in the session is probably not doing any good. You could use a session as a personal data cache, for not too large amounts of data.

The problem with sessions is that they're global. Per user, or rather, per browser, yes, but still global. Tracking form validation flow with a session, in the simplest implementation, will only work well as long as the user doesn't have more than one form open in a browser; just like, in webmail, you can only be logged in into one mail account at a time.

If you're using a session to track form flow, it's best to have a unique form id per form, and track flow per form id: put the form data in a subarray keyed by form id instead of at the root level. You may have to add logic to prevent this data to hang around forever so it'll just keep growing, by either limiting lifetime, or number of active forms (using "least recently used" to decide which form to purge once full), or both.

Answer 4

Any information whos public usage would not cause any issue.

A good use of sessions is keeping track of items in a shopping cart, although at checkout you would always want to fetch the items from the database.

Answer 5

The most common scenario where the sessions come in handy is to keep the user identification. Usually this requires only keeping the user id or an array of data related to the currently logged user.

I think the only data type you can not store is resource. There's a reason behind this limitation :)

It is wrong to use the session as a caching mechanism. You should avoid that at all cost. There are other solutions available if you pursue caching (ex. xcache, apc).