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

Reply via email to