note 16218 rejected from ref.session by jimw

I posted this comment earlier today, it appeared in manual. Then was mysteriously deleted. I will keep resubmitting it every time it doesn't appear until someone explains why they are censoring my comments. Users of PHP have a right to know this information and should protest censorship. Is this not open source? Using cookies for storing session id is a very poor technique and fraught with bugs. 1. You've got to make sure cookies are on, because the automated SID fall back mechanism of PHP (if --enable-trans-sid is on) will not work correctly with <form>s using method=post, as well as certain programmatic links, such as Javascript. You would have to manually insert session_name() and session_id() in these cases (e.g. see item #3 below). This is all possible to do and I have done it, but it requires manually doctoring the method=post <forms>, so it has no real advantage over the technique I will describe below, and it does have several bugs as described next. 2. The main problem with storing the session id in a cookie is that it is global to all open windows of the browser. Thus the first case is if user presses Back (unless you disable Back button with PHP's default session.cache_limiter =nocache; setting, which of itself is very annoying...try IE5.5 on authorize.net or other popular site done with PHP). Or the second cases are if user creates a New Window of current page of session, or if user logins in again with another browser window, then operates from both windows. (There are even more buggy scenarios such as the meta refresh, etc) In all 3 of these cases, when the page is revalidated or resubmitted then the GET or POST variables of the page are going to be out of sync with the session data on the server. If data (input variable) names happen to collide, then depending on the sophistication of your validation of client inputs, then all kinds of unexpected things could happen, such as setting database records to unintended values, etc.. So using cookies to hold the session id, forces the use of nocache which kills the Back capability, but does nothing to stop the bugs if user opens new window on copy, or logs in simultaneously to 2 or more windows. Actually Back is not even killed entirely. The user can still activated the bug by refreshing the page after issuing Back. 3. I've devised the following class which should be instantiated on each page of session before any html is output. NOTE THIS CLASS IS NOT YET TESTED (this is all from my head). I look forward to other's comments on testing and use of this. This class requires each GET link url be appended with "?" . session_name() . "=" . session_id(), and that each <FORM method=post> add "<INPUT type=hidden name='" . session_name() . "' value='" . session_id() . "'>". Instead of doctoring each url link or form, if you prefer then I refer to technique I found in this annotated manual (http://www.php.net/manual/en/ref.session.php, chernyshevsky@hotmail.com, 25-Aug-2000 04:26) for using DOM to automatically adding this information. However, his technique is flawed in that you should replace "SID" with session_name() . "=" . session_id(), and add use dhtml to add proper hidden input to form (because post and get can't occur simultaneously as in his code). Note in the following class that I asume register_globals is off, because register_globals will cause a multitude of security holes if on. The class follows in next message.