There doesn't seem to be much discussion of the disadvantages and long term dangers of using php "sessions". So let's redress the balance:
1. Heterogeneous Code Environments
php session data is not easily accessible from non-php code e.g. Perl/C/ASP etc. In contrast, either client-stored data e.g. cookies, hidden posts, get variables, or data stored in a structured database table, (i.e. one column per variable), is easily accessible from other code.
The implication is that sessions may suit you fine as long as only php is used on your site. However, if your site matures and you ever want or need to use another language for some pages, it will be hard for those pages to access data stored in sessions. On the other hand, if the data had been stored in an well-established industry standard format, you should have no problems.
2. Provably Secure Authentication Data
Hopefully we all know by now that the best way to safely authenticate for access control is to make sure the username/password is checked every time either by your script, your webserver or a trusted third-party.
However, I have the feeling some session users are tempted to simply authenticate in one script and store a "logged in" or username flag in the session without the username/password having been re-validated.
It's not a complete disaster if you do this, which probably means lots of people do it! But this is only as secure as the session_id key. I don't doubt that session_ids are generated with a high-quality random number generator and should be suitably uncrackable.
However, the crackability/vulnerability of a username/password schema is very well understood. Can we really say that the vulnerability/crackability of a session_id is as well understood?
What happens if, and I'm sure it's a remote chance, there is ever a bug in the session-key generation that stops them being so random so a "session_id" crack becomes not just possible but real easy!
Usernames/passwords just don't have that kind of vulnerability, and the vulnerabilities they do have are well known.
3. Independent Audit of Server Stored Data
Procedures for independently verifying the data stored on a server in a SQL RDBMs are well established. It is easy to query the database schema to see what columns are defined. It is easy to verify that the data actually held in a column is as expected. In general it is easy to prove and verify what data is held e.g. to prove Data Protection compliance or Bank/Credit Card requirements, (no storage of cvv2 for example).
It is intrinsically much harder to prove that the contents of php session data are compliant. You need to write a php script to unpack the session data. That means proving that that script itself is safe.
Even after you've unpacked the session data, you still have to make sense of it. Different sessions may hold different numbers of differently named variables. But that's not all, the same variable may hold data in different formats in different sessions!
Practically you have some pretty complex processes to prove what data you have stored and to verify that you have stored what you thought you'd stored!
All in all, php sessions are NOT going to be popular with data auditors. Once again, that may not matter to you now, but down the line it could become a BIG issue.
4. State-ful Designs
My personal concern about sessions, is more about the design issues. What worries me is that sessions may be used to try and re-create client/server style "state" when the most distinctive advantage of the internet, (and the key to its astounding success), is that it is fundamentally state-less.
What this means, is that the internet is based on the principle that every request is entirely self-contained and independent of any other request. There is for example, absolutely and explicitly, no guarantee that http requests will be received in chronological order. It is all strictly about "best effort", and no guarantees. This is why the internet works: each component does its own job as well as it can without worrying about what else is happening.
The implication from a design point of view is that you should not be making any assumptions about what has "gone before" or what "will come after" your php script runs. The functionality offered, should, as far as possible, be completely self-contained, with each php script acting as a "component" in its own right. That means no direct interaction between the scripts. Interaction should be gated through third-party standard interfaces such as http or SQL.
The problem with sessions is that they encourage you to break this model by creating a new set of "super-global" data holding "state" information. This data is not exchanged through established standards, but rather, "floats around" in the background, changing the behaviour of the script but without being clearly externally defined.
If the session data is only concerned with "cosmetic" data such as user style and colour preferences, this doesn't particularly matter. But if it holds important or critical data, it does matter. Each script is no longer a well-defined self-contained component, but more or less intimately bound up with other scripts that share the same session.
It's worth remembering that there is nothing remotely new about "state-ful" design. VDUs connected to mainframes are about as state-ful as you can get. Indeed, the single distinctive feature of the two most successful software technologies of all time, (the internet and SQL), is that, (unlike their predecessors), they are both fundamentally state-less protocols.
5. Reduced Component Reusability
A practical example of the problems of this style of "state-ful" code is in reduced reusability of the components, (php scripts in this case). One of the great benefits of the internet's stateless approach is the tremendous ease with which uri-addressable components can be reused. For example, a single graphic can be very easily used on any web page, anywhere, anytime, with no additional effort than making it available on one web page on one site, once.
Similarily, php scripts which are properly structured components, (e.g. no significant session data use), can be reused, without code change for many different purposes. If session data is used, e.g. to pass search criteria or results data between pages, this flexibility is significantly reduced.
For example, it's very handy when maintaining data in one table, to be able to offer direct links to updates of related data. But if the update form for the related data is coded to expect the details of what it must update from session data e.g. to have been set from a search/list/select page, this won't work. So, just because you used sessions, you, (or someone else), may not be able to offer direct links, (or bookmarks), to the update page even when the appropriate database keys are already known. You either have to force the user to duplicate effort by unnecessary traversing of a new search/list/select or you have to write new code to handle this new type of request.
On the other hand if the update is coded as a proper component i.e. it reads the key of the data to be updated from the http request, (GET, POST or COOKIE), then you can automatically allow it to be accessed from anywhere without having to always go through some particular search/list/select sequence.
This is one, among many possible, examples of how, by establishing a hidden, private, relationship between php scripts, session data automatically and inevitably reduces the accessibility of the functionality of the script.
There is a direct parallel in "lower-level" code structures. Over use of session data is as intrinsically hostile to code re-use as over use of global data to communicate between distinct functions or objects. Just as functions and objects should use the "public" interface to exchange data i.e. arguments/methods/properties, so php scripts should exchange data via "public" interfaces i.e. http requests, databases etc.
Well, I've convinced myself. Of course, as I don't use sessions I may have missed something, (or everything). So, please, what have I got wrong?
George
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
