On Fri, 30 May 2003, George Whiffen wrote: > 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.
For anything beyond a trivial application, you are going to be writing your own backend save_handler anyway, so I don't really see how this is an issue. If you don't want to write your own save_handler (which is really really easy) you can always just set "session.serialize_handler = wddx" in your php.ini file and you will have the data stored in a standard XML format instead. This format is very accessible from non-PHP code. > 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. Sure, but this isn't really specific to sessions. I would say this is related to any cookie a developer might create. There is always the temptation to not include the auth headers on each page and just toss the logged in user id into the cookie. This is obviously a bad idea, but I wouldn't necessarily attribute this to an inherent danger in sessions. > 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! Again, see point 1. Any real usage of sessions is going to need a custom save_handler most likely written against a real database. You simply cannot go beyond a trivial single-server web-app without doing so and the facilities in the php session support for doing this is good. > 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 boat has long since sailed on this one. People need and want to maintain state. You can't build any sort of shopping-cart style site without them. > 5. Reduced Component Reusability > > ... > > 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. I tend to distinguish between the human interface to an app and the machine interface. Trying to put them both into the same interface tends to make them cumbersome for both sides. Often the human interface is just a thin layer on top of an underlying machine interface and it is at the machine interface that you have your reusability and transparency. In a properly designed architecture, the session layer is simply part of the human interface and really doesn't affect the reusability of your base machine interface. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
