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
On Wed, 2009-07-22 at 03:45 +0700, Lenin wrote:
On Wed, Jul 22, 2009 at 3:24 AM, L.Guruprasad lgp171...@gmail.com 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
On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
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
On Wed, 2009-07-22 at 16:07 +0700, Lenin wrote:
On Wed, Jul 22, 2009 at 2:46 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
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
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,
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
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
On Wed, Jul 22, 2009 at 8:36 AM, Ashley
Sheridana...@ashleysheridan.co.uk 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 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
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,
On Wed, Jul 22, 2009 at 9:59 AM, Robert Cummingsrob...@interjinn.com 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
Andrew Ballard wrote:
On Wed, Jul 22, 2009 at 9:59 AM, Robert Cummingsrob...@interjinn.com 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
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 lgp171...@gmail.com wrote:
Hi all,
I have a doubt with creating
On Jul 21, 2009, at 3:12 PM, Guruprasad lgp171...@gmail.com 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
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
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
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 lgp171...@gmail.com wrote:
Hi,
Floyd Resler wrote:
Keep in mind that sessions are based on the domain. I've run into
situations where someone will be
On Wed, Jul 22, 2009 at 3:24 AM, L.Guruprasad lgp171...@gmail.com 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
18 matches
Mail list logo
