Justin French wrote: > > Hi all, > > About 2.30 in the morning I started kicking around an idea, based on the > recent discussions on sessions, and what --enable-trans-sid did. > > From my understanding: > > + if there is no session cookie, set a cookie AND append a > session ID to URLs on the first (session start) page
+ CREATE THAT PHP SESSION as soon as the sid is generated. And THEN redirect to self > > + on the next page, the session is carried, and it checks to > see if the cookie set on the prev. page can be found > > - if it can, it now knows (presumably by setting a session > var) that cookies are okay > > - if it can't, it assumes cookies are not avail, and it > knows that the session must be appended to each URL > + IF THE SESSION IS FOUND EXISTENT. It should, because you created it when generated the sid, before doing the redirect to self. Otherwise someone is spoofing. I've recently modified the PHPLIB behavior about session creation policy, to behave like this. The patch is commited and published at the project's site. > + if the session ID must be appended, it waves a magic wand > over every .php page and appends a session id... i GUESS > through buffering or parsing the entire output. > > So, couldn't this be emulated by : > > + following the same set/check routine above > + if needed, wave a magic wand over the output before it's sent to the page, > by the use of output buffering? > > If some enough ppl on this list believe it's a good idea to pursue this, and > don't think it will result in a big performance drop or anything, I'm keen > to start work on it as an opensource project, hopefully with the support of > this list to make sure it stays on the right track. > > On the other hand, there may be a huge flaw in my idea :D > > Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
