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
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
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 wha
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, a
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 Bal
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 acce
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
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 al
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
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
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 mo
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
> >
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 sit
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
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 ha
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 doma
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 virtualho
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 sessi
18 matches
Mail list logo
