Doubt regarding session_destroy() in PHP 5

Hi all,
I have a doubt with creating and destroying sessions in PHP using
session_destroy(). Supposing there is a PHP-based website hosted on a
web server. Now I add another site that I developed using PHP on that
web server using virtualhost. I destroy a session in my website using
session_destroy() which will destroy all the session variables
associated with my website.

What will happen if I have the other website in another tab with similar
session variable names? Will the session variables of that website be
destroyed too? Or will the session variables be associated with the
session id so that only the appropriate website's session variables will
get destroyed?

Thanks in advance.

Regards,
Guruprasad

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

--0015175caa2a8aea82046f3ce590
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Yes. You are right. Session variables are associated with the session id so
only that appropriate website's session variables will get destroyed.
You can try it in your local system.

On Wed, Jul 22, 2009 at 12:42 AM, Guruprasad wrote:

> Hi all,
> I have a doubt with creating and destroying sessions in PHP using
> session_destroy(). Supposing there is a PHP-based website hosted on a web
> server. Now I add another site that I developed using PHP on that web server
> using virtualhost. I destroy a session in my website using session_destroy()
> which will destroy all the session variables associated with my website.
>
> What will happen if I have the other website in another tab with similar
> session variable names? Will the session variables of that website be
> destroyed too? Or will the session variables be associated with the session
> id so that only the appropriate website's session variables will get
> destroyed?
>
> Thanks in advance.
>
> Regards,
> Guruprasad
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Devendra Jadhav

--0015175caa2a8aea82046f3ce590--

Re: Doubt regarding session_destroy() in PHP 5

On Jul 21, 2009, at 3:12 PM, Guruprasad wrote:

> Hi all,
> I have a doubt with creating and destroying sessions in PHP using
> session_destroy(). Supposing there is a PHP-based website hosted on
> a web server. Now I add another site that I developed using PHP on
> that web server using virtualhost. I destroy a session in my website
> using session_destroy() which will destroy all the session variables
> associated with my website.
>
> What will happen if I have the other website in another tab with
> similar session variable names? Will the session variables of that
> website be destroyed too? Or will the session variables be
> associated with the session id so that only the appropriate
> website's session variables will get destroyed?
>

Each session has it's own id and therefore each session will just have
it's own data destroyed



> Thanks in advance.
>
> Regards,
> Guruprasad
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Bastien

Sent from my iPod


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

Keep in mind that sessions are based on the domain. I've run into
situations where someone will be working in several different sites
that we host. Each site is accessed via http://domain/site. Each
site has it's own database, users, etc. However, because they all
hang off the same domain, they get one session. That can really mess
things up for the users as they go from site to site. I got around
this by using MySQL-based sessions. It keeps things nice and separated.

Take care,
Floyd

On Jul 21, 2009, at 4:14 PM, Devendra Jadhav wrote:

> Yes. You are right. Session variables are associated with the
> session id so
> only that appropriate website's session variables will get destroyed.
> You can try it in your local system.
>
> On Wed, Jul 22, 2009 at 12:42 AM, Guruprasad
> wrote:
>
>> Hi all,
>> I have a doubt with creating and destroying sessions in PHP using
>> session_destroy(). Supposing there is a PHP-based website hosted on
>> a web
>> server. Now I add another site that I developed using PHP on that
>> web server
>> using virtualhost. I destroy a session in my website using
>> session_destroy()
>> which will destroy all the session variables associated with my
>> website.
>>
>> What will happen if I have the other website in another tab with
>> similar
>> session variable names? Will the session variables of that website be
>> destroyed too? Or will the session variables be associated with the
>> session
>> id so that only the appropriate website's session variables will get
>> destroyed?
>>
>> Thanks in advance.
>>
>> Regards,
>> Guruprasad
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> Devendra Jadhav


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

Hi,
Floyd Resler wrote:
> Keep in mind that sessions are based on the domain. I've run into
> situations where someone will be working in several different sites that
> we host. Each site is accessed via http://domain/site. Each site has
> it's own database, users, etc. However, because they all hang off the
> same domain, they get one session. That can really mess things up for
> the users as they go from site to site. I got around this by using
> MySQL-based sessions. It keeps things nice and separated.
>
> Take care,
> Floyd

Will this be causing issues when http://1.a.b and http://2.a.b are the
two PHP sites running on the same web server using virtualhosts?

Regards,
Guruprasad

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

--0015175d0a827ad712046f3d4628
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

By default sub-domains do not share sessions but you can make them to share
the session

On Wed, Jul 22, 2009 at 1:54 AM, L.Guruprasad wrote:

> Hi,
> Floyd Resler wrote:
>
>> Keep in mind that sessions are based on the domain. I've run into
>> situations where someone will be working in several different sites that we
>> host. Each site is accessed via http://domain/site. Each site has it's
>> own database, users, etc. However, because they all hang off the same
>> domain, they get one session. That can really mess things up for the users
>> as they go from site to site. I got around this by using MySQL-based
>> sessions. It keeps things nice and separated.
>>
>> Take care,
>> Floyd
>>
>
> Will this be causing issues when http://1.a.b and http://2.a.b are the two
> PHP sites running on the same web server using virtualhosts?
>
> Regards,
> Guruprasad
>



--
Devendra Jadhav

--0015175d0a827ad712046f3d4628--

Re: Doubt regarding session_destroy() in PHP 5

--00163646cb549297a0046f3d55a9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Jul 22, 2009 at 3:24 AM, L.Guruprasad wrote:

> Hi,
> Floyd Resler wrote:
>
>> Keep in mind that sessions are based on the domain. I've run into
>> situations where someone will be working in several different sites that we
>> host. Each site is accessed via http://domain/site. Each site has it's
>> own database, users, etc. However, because they all hang off the same
>> domain, they get one session. That can really mess things up for the users
>> as they go from site to site. I got around this by using MySQL-based
>> sessions. It keeps things nice and separated.
>>
>> Take care,
>> Floyd
>>
>
> Will this be causing issues when http://1.a.b and http://2.a.b are the two
> PHP sites running on the same web server using virtualhosts?
>
As Floyd suggested keeping your sessions in the DB will give you better
session management and security as well.

--00163646cb549297a0046f3d55a9--

Re: Doubt regarding session_destroy() in PHP 5

On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
> On Wed, Jul 22, 2009 at 3:24 AM, L.Guruprasad wrote:
>
> > Hi,
> > Floyd Resler wrote:
> >
> >> Keep in mind that sessions are based on the domain. I've run into
> >> situations where someone will be working in several different sites that we
> >> host. Each site is accessed via http://domain/site. Each site has it's
> >> own database, users, etc. However, because they all hang off the same
> >> domain, they get one session. That can really mess things up for the users
> >> as they go from site to site. I got around this by using MySQL-based
> >> sessions. It keeps things nice and separated.
> >>
> >> Take care,
> >> Floyd
> >>
> >
> > Will this be causing issues when http://1.a.b and http://2.a.b are the two
> > PHP sites running on the same web server using virtualhosts?
> >
> As Floyd suggested keeping your sessions in the DB will give you better
> session management and security as well.

Why would putting the session data in a database offer more security?
I'm not meaning to try and poke holes in your idea, I genuinely don't
know the answer!

Thanks
Ash
www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

--001636427377343d30046f47b644
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
wrote:

> On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
>


> > >
> > As Floyd suggested keeping your sessions in the DB will give you better
> > session management and security as well.
>
> Why would putting the session data in a database offer more security?
> I'm not meaning to try and poke holes in your idea, I genuinely don't
> know the answer!
>
> *Storing Session Data In A Database
*When you use on-disk files to store session data, those files must be
readable and writeable by PHP. On a multi-user hosting system, it is
possible for other users to access your session data through the PHP process
(but see the commentary on open_basedir in part 5 of this series. The best
way to secure your session data is to store it in a database.

source: http://www.acunetix.com/websitesecurity/php-security-6.htm

I have also studied Zend Certification Study guide by Davey Shafik and Ben
Ramsey who said similar things in the book.


Lenin

http://twitter.com/nine_L

--001636427377343d30046f47b644--

Re: Doubt regarding session_destroy() in PHP 5

On Wed, 2009-07-22 at 16:07 +0700, Lenin wrote:
> On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
> wrote:
>
> > On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
> >
>
>
> > > >
> > > As Floyd suggested keeping your sessions in the DB will give you better
> > > session management and security as well.
> >
> > Why would putting the session data in a database offer more security?
> > I'm not meaning to try and poke holes in your idea, I genuinely don't
> > know the answer!
> >
> > *Storing Session Data In A Database
> *When you use on-disk files to store session data, those files must be
> readable and writeable by PHP. On a multi-user hosting system, it is
> possible for other users to access your session data through the PHP process
> (but see the commentary on open_basedir in part 5 of this series. The best
> way to secure your session data is to store it in a database.
>
> source: http://www.acunetix.com/websitesecurity/php-security-6.htm
>
> I have also studied Zend Certification Study guide by Davey Shafik and Ben
> Ramsey who said similar things in the book.
>
>
> Lenin
>
> http://twitter.com/nine_L

And is the database not readable and writeable by PHP? Just seems that
this sort of thing could be properly sorted by the right permissions
level on the file, as I assume you'd be protecting the database in a
similar manner by locking down that to specific users, and determining
what they could and couldn't do.

Thanks
Ash
www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

You can do so much more with storing sessions in a database. For
example, I can determine which of my users is currently on by looking
in the sessions table. Not only does using a database for sessions
offer more security, it also offers more flexibility.

Take care,
Floyd

On Jul 22, 2009, at 5:13 AM, Ashley Sheridan wrote:

> On Wed, 2009-07-22 at 16:07 +0700, Lenin wrote:
>> On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
>> wrote:
>>
>>> On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
>>>
>>
>>
>>>>>
>>>> As Floyd suggested keeping your sessions in the DB will give you
>>>> better
>>>> session management and security as well.
>>>
>>> Why would putting the session data in a database offer more
>>> security?
>>> I'm not meaning to try and poke holes in your idea, I genuinely
>>> don't
>>> know the answer!
>>>
>>> *Storing Session Data In A Database
>> *When you use on-disk files to store session data, those files must
>> be
>> readable and writeable by PHP. On a multi-user hosting system, it is
>> possible for other users to access your session data through the
>> PHP process
>> (but see the commentary on open_basedir in part 5 of this series.
>> The best
>> way to secure your session data is to store it in a database.
>>
>> source: http://www.acunetix.com/websitesecurity/php-security-6.htm
>>
>> I have also studied Zend Certification Study guide by Davey Shafik
>> and Ben
>> Ramsey who said similar things in the book.
>>
>>
>> Lenin
>>
>> http://twitter.com/nine_L
>
> And is the database not readable and writeable by PHP? Just seems that
> this sort of thing could be properly sorted by the right permissions
> level on the file, as I assume you'd be protecting the database in a
> similar manner by locking down that to specific users, and determining
> what they could and couldn't do.
>
> Thanks
> Ash
> www.ashleysheridan.co.uk
>
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

On Wed, 2009-07-22 at 08:32 -0400, Floyd Resler wrote:
> You can do so much more with storing sessions in a database. For
> example, I can determine which of my users is currently on by looking
> in the sessions table. Not only does using a database for sessions
> offer more security, it also offers more flexibility.
>
> Take care,
> Floyd
>
> On Jul 22, 2009, at 5:13 AM, Ashley Sheridan wrote:
>
> > On Wed, 2009-07-22 at 16:07 +0700, Lenin wrote:
> >> On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
> >> wrote:
> >>
> >>> On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
> >>>
> >>
> >>
> >>>>>
> >>>> As Floyd suggested keeping your sessions in the DB will give you
> >>>> better
> >>>> session management and security as well.
> >>>
> >>> Why would putting the session data in a database offer more
> >>> security?
> >>> I'm not meaning to try and poke holes in your idea, I genuinely
> >>> don't
> >>> know the answer!
> >>>
> >>> *Storing Session Data In A Database
> >> *When you use on-disk files to store session data, those files must
> >> be
> >> readable and writeable by PHP. On a multi-user hosting system, it is
> >> possible for other users to access your session data through the
> >> PHP process
> >> (but see the commentary on open_basedir in part 5 of this series.
> >> The best
> >> way to secure your session data is to store it in a database.
> >>
> >> source: http://www.acunetix.com/websitesecurity/php-security-6.htm
> >>
> >> I have also studied Zend Certification Study guide by Davey Shafik
> >> and Ben
> >> Ramsey who said similar things in the book.
> >>
> >>
> >> Lenin
> >>
> >> http://twitter.com/nine_L
> >
> > And is the database not readable and writeable by PHP? Just seems that
> > this sort of thing could be properly sorted by the right permissions
> > level on the file, as I assume you'd be protecting the database in a
> > similar manner by locking down that to specific users, and determining
> > what they could and couldn't do.
> >
> > Thanks
> > Ash
> > www.ashleysheridan.co.uk
> >
> >
>
But *how* does it offer more security? You've not actually mentioned
that!

Thanks
Ash
www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

With proper permissions I'm not sure that it's any more secure but it
certainly is a whole lot more scalable. And it is very easy to set
up. A web search will yield a lot of examples of using a database. I
use a PHP class which I really like.

Take care,
Floyd

On Jul 22, 2009, at 8:36 AM, Ashley Sheridan wrote:

> On Wed, 2009-07-22 at 08:32 -0400, Floyd Resler wrote:
>> You can do so much more with storing sessions in a database. For
>> example, I can determine which of my users is currently on by looking
>> in the sessions table. Not only does using a database for sessions
>> offer more security, it also offers more flexibility.
>>
>> Take care,
>> Floyd
>>
>> On Jul 22, 2009, at 5:13 AM, Ashley Sheridan wrote:
>>
>>> On Wed, 2009-07-22 at 16:07 +0700, Lenin wrote:
>>>> On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
>>>> wrote:
>>>>
>>>>> On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
>>>>>
>>>>
>>>>
>>>>>>>
>>>>>> As Floyd suggested keeping your sessions in the DB will give you
>>>>>> better
>>>>>> session management and security as well.
>>>>>
>>>>> Why would putting the session data in a database offer more
>>>>> security?
>>>>> I'm not meaning to try and poke holes in your idea, I genuinely
>>>>> don't
>>>>> know the answer!
>>>>>
>>>>> *Storing Session Data In A Database
>>>> *When you use on-disk files to store session data, those files must
>>>> be
>>>> readable and writeable by PHP. On a multi-user hosting system, it
>>>> is
>>>> possible for other users to access your session data through the
>>>> PHP process
>>>> (but see the commentary on open_basedir in part 5 of this series.
>>>> The best
>>>> way to secure your session data is to store it in a database.
>>>>
>>>> source: http://www.acunetix.com/websitesecurity/php-security-6.htm
>>>>
>>>> I have also studied Zend Certification Study guide by Davey Shafik
>>>> and Ben
>>>> Ramsey who said similar things in the book.
>>>>
>>>>
>>>> Lenin
>>>>
>>>> http://twitter.com/nine_L
>>>
>>> And is the database not readable and writeable by PHP? Just seems
>>> that
>>> this sort of thing could be properly sorted by the right permissions
>>> level on the file, as I assume you'd be protecting the database in a
>>> similar manner by locking down that to specific users, and
>>> determining
>>> what they could and couldn't do.
>>>
>>> Thanks
>>> Ash
>>> www.ashleysheridan.co.uk
>>>
>>>
>>
> But *how* does it offer more security? You've not actually mentioned
> that!
>
> Thanks
> Ash
> www.ashleysheridan.co.uk
>
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

On Wed, Jul 22, 2009 at 8:36 AM, Ashley
Sheridan wrote:
> But *how* does it offer more security? You've not actually mentioned
> that!
>

One way would be to encapsulate data access in stored procedures and
deny direct table access on the session data. That way, even though
the PHP account has access to the database where all sessions are
stored, it can only call a ReadSession procedure that requires the
session_id() as a parameter. That way, PHP would have to know the ID
of the session and could not simply SELECT * FROM sessions.

However, I haven't found many examples that use stored procedures.
Most just use regular INSERT/SELECT/UPDATE/DELETE statements, which
means that the PHP user has full access to the entire table. In that
case, it's no more trivial to scan the session table than it is to
scan the session save path looking for interesting stuff.

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

The nice thing about the database, though, is that you can specify
which MySQL user has access to the sessions table. That way you can
really lock it down by giving access to only INSERT, SELECT, UPDATE,
and DELETE just for that table.

Thanks!
Floyd

On Jul 22, 2009, at 9:36 AM, Andrew Ballard wrote:

> On Wed, Jul 22, 2009 at 8:36 AM, Ashley
> Sheridan wrote:
>> But *how* does it offer more security? You've not actually mentioned
>> that!
>>
>
> One way would be to encapsulate data access in stored procedures and
> deny direct table access on the session data. That way, even though
> the PHP account has access to the database where all sessions are
> stored, it can only call a ReadSession procedure that requires the
> session_id() as a parameter. That way, PHP would have to know the ID
> of the session and could not simply SELECT * FROM sessions.
>
> However, I haven't found many examples that use stored procedures.
> Most just use regular INSERT/SELECT/UPDATE/DELETE statements, which
> means that the PHP user has full access to the entire table. In that
> case, it's no more trivial to scan the session table than it is to
> scan the session save path looking for interesting stuff.
>
> Andrew
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

Floyd Resler wrote:
> The nice thing about the database, though, is that you can specify
> which MySQL user has access to the sessions table. That way you can
> really lock it down by giving access to only INSERT, SELECT, UPDATE,
> and DELETE just for that table.
>
> Thanks!
> Floyd
>
> On Jul 22, 2009, at 9:36 AM, Andrew Ballard wrote:
>
>> On Wed, Jul 22, 2009 at 8:36 AM, Ashley
>> Sheridan wrote:
>>> But *how* does it offer more security? You've not actually mentioned
>>> that!
>>>
>> One way would be to encapsulate data access in stored procedures and
>> deny direct table access on the session data. That way, even though
>> the PHP account has access to the database where all sessions are
>> stored, it can only call a ReadSession procedure that requires the
>> session_id() as a parameter. That way, PHP would have to know the ID
>> of the session and could not simply SELECT * FROM sessions.
>>
>> However, I haven't found many examples that use stored procedures.
>> Most just use regular INSERT/SELECT/UPDATE/DELETE statements, which
>> means that the PHP user has full access to the entire table. In that
>> case, it's no more trivial to scan the session table than it is to
>> scan the session save path looking for interesting stuff.

A custom session handler that writes to files could easily encrypt
session data so that only the user with the correct session ID can
decrypt it. I think you're confusing the issue by claiming database
sessions are more secure when what you really mean is that custom
sessions are more secure than the default session system.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

On Wed, Jul 22, 2009 at 9:59 AM, Robert Cummings wrote:
> A custom session handler that writes to files could easily encrypt session
> data so that only the user with the correct session ID can decrypt it. I
> think you're confusing the issue by claiming database sessions are more
> secure when what you really mean is that custom sessions are more secure
> than the default session system.
>

What would you use for the encryption key? (I'm not saying you're
wrong here; I'm just not sure I see it.) If the key is the same for
all requests, then it is no more secure than if they were unencrypted,
other than not being able to read the contents in a text editor. If it
is based on the session_id, you can get that from the file name.
That's a little more secure, but not much. A value stored in $_SESSION
is out, for obvious reasons. I guess you could store the key in
$_COOKIE or even a use a combination of (or hash derived from)
session_id() and another value stored in $_COOKIE as the key.

It seems to me that anything you can do to make file-based sessions
secure could also be layered into a database approach, making the
database sessions even that much more secure.

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

Andrew Ballard wrote:
> On Wed, Jul 22, 2009 at 9:59 AM, Robert Cummings wrote:
>> A custom session handler that writes to files could easily encrypt session
>> data so that only the user with the correct session ID can decrypt it. I
>> think you're confusing the issue by claiming database sessions are more
>> secure when what you really mean is that custom sessions are more secure
>> than the default session system.
>>
>
> What would you use for the encryption key? (I'm not saying you're
> wrong here; I'm just not sure I see it.) If the key is the same for
> all requests, then it is no more secure than if they were unencrypted,
> other than not being able to read the contents in a text editor. If it
> is based on the session_id, you can get that from the file name.
> That's a little more secure, but not much. A value stored in $_SESSION
> is out, for obvious reasons. I guess you could store the key in
> $_COOKIE or even a use a combination of (or hash derived from)
> session_id() and another value stored in $_COOKIE as the key.
>
> It seems to me that anything you can do to make file-based sessions
> secure could also be layered into a database approach, making the
> database sessions even that much more secure.
>
> Andrew

Well, if you're using a custom session handler to encrypt the files,
then you can also determine what the session file names are. So don't
put the session id in the file name. Maybe use a secure hash of the
session id for the filename and then use the session id as the
encryption key.


--
Thanks!
-Shawn
http://www.spidean.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Doubt regarding session_destroy() in PHP 5

Ashley Sheridan a écrit :
> But *how* does it offer more security? You've not actually mentioned
> that!

Because you need database slice access to manage the session, and not
only file access in /tmp/ (where sessions belongs, by default). So now
the problem is : and what about the configuration file that lies in my
filesystem ? :D

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Seeking for a position

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php