hi, Like I said before, this discussion is not about the method by which an SID is propogated nor generated. It is about: 1) knowing when it is safe to display sensative information -> user education 2) the possibility to verify credentials, besides the SID.
Given 2), the easiest solution is to provide a callback and some predefined methods. These have nothing to do, with the filemtime/atime - not even with the session. This callback can be as simple as: function session_is_valid() { return (mysql_result(mysql_unbuffered_query("SELECT COUNT(1) AS num FROM usertable WHERE user='$_SERVER[PHP_AUTH_USER]' AND pass='$_SERVER[PHP_AUTH_PW]'",0,"num") == 1); } But one could also stick an IDENT lookup in there, or whatever...don't focus on the methods, but the principle. As you can see it doesn't take any arguments nor even looks at the session. It is also not about what could go wrong - it is about what is required as a security level for the application and providing methods to the webdeveloper to detect and act upon an invalid session. If this means, that a bank app cannot allow AOL-proxied users to do banking, then so be it. On the other hand - if the bank management thinks about profit rather than security, than the callback can be omitted or tailored to AOL proxy behaviors. PHP needs to enable the developer and educate to a certain level - as Rasmus has said early on "so that the developer can make informed descisions". All this verification of the session by the session, only leads to cludder and will never be totally secure. Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php