The only reason session data is stored in /tmp is that we want sessions to
work out of the box and /tmp is the only place we can be semi-sure that we
will have write access to.  People who run large servers with multiple
sites that all use sessions should of course change the session directory
on a per-server basis in their httpd.conf file, or better yet, write their
own session back end handler.

If we shipped PHP with sessions that did not work out of the box, we would
get flooded with questions here.

The general philosophy of PHP has always been to make PHP easy for the
beginner yet flexible enough for advanced users.  This fits that rule.
Give the advanced users the tools to configure PHP to have per-virtualhost
session handling, while sessions still work for the guy who just installed
PHP on his own little server and really doesn't know what he is doing.

-Rasmus

On Fri, 1 Feb 2002, Ivan Ristic wrote:

> > Also, ISPs (like AOL) who use farms of proxy caches will change a users
> > apparent ip during a single session.  (i.e. concurrent requests may come
> > from different ips).
>
>   The real IP address can be tracked in most cases (say, using the
>   HTTP_X_FORWARDED header an others) but I am not really sure that we
>   should put the logic for that in the PHP engine itself. Users can
>   add the additional PHP code to their libraries. Anyway, you can
>   change the session id from the PHP code itself.
>
>   I am more afraid of several applications (web sites) sharing the
>   same session directory. Can a sessionid from one site be used
>   as a sessionid for the other site residing on the same server
>   (provided that session files are stored in the same directory)?
>   From all the tests I've done - it can.
>
>   This would allow an intruder to construct session data with any
>   kind of variables and then switch to the other application with
>   arbitrary privileges.
>
>   ASP-s are most vulnarable here. If two instances of the same
>   applications are running on the same server, then the administrator
>   of one application can quite possibly become the administrator
>   of the other...
>
> --
> Ivan Ristic, [EMAIL PROTECTED]
> [ Weblog on PHP, Software development, Intranets,
> and Knowledge Management: http://www.webkreator.com ]
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to