php-general Digest 4 Dec 2011 16:38:42 -0000 Issue 7597
Topics (messages 315924 through 315930):
End of session clean-up
315924 by: Andre Majorel
315926 by: Stuart Dallas
315927 by: Andre Majorel
315928 by: Stuart Dallas
Re: Common way to store db-password of open session?
315925 by: Stuart Dallas
315929 by: Tamara Temple
315930 by: Jim Giner
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hello all. I need to purge old records from application tables
when a session expires. How do I register a callback with the
end-of session-garbage collection system ?
session_set_save_handler() lets me override the native garbage
collection, not *add* to it, as far as I can tell.
Thanks in advance.
--
André Majorel http://www.teaser.fr/~amajorel/
--- End Message ---
--- Begin Message ---
On 3 Dec 2011, at 16:57, Andre Majorel wrote:
> Hello all. I need to purge old records from application tables
> when a session expires. How do I register a callback with the
> end-of session-garbage collection system ?
> session_set_save_handler() lets me override the native garbage
> collection, not *add* to it, as far as I can tell.
You would need to implement a complete session handler to add your own
functionality into the GC.
However, the fact that you want to do this begs the question, why are you
storing what sounds like session data in application tables instead of storing
them in the session?
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 2011-12-03 17:41 +0000, Stuart Dallas wrote:
> On 3 Dec 2011, at 16:57, Andre Majorel wrote:
>
> > Hello all. I need to purge old records from application tables
> > when a session expires. How do I register a callback with the
> > end-of session-garbage collection system ?
> > session_set_save_handler() lets me override the native garbage
> > collection, not *add* to it, as far as I can tell.
>
> You would need to implement a complete session handler to add
> your own functionality into the GC.
Rats.
> However, the fact that you want to do this begs the question,
> why are you storing what sounds like session data in
> application tables instead of storing them in the session?
This "session data" is similar to a purchase basket. It
references tuples from the static tables. If it's outside of the
database, we lose the benefits of a relational DBMS.
--
André Majorel http://www.teaser.fr/~amajorel/
--- End Message ---
--- Begin Message ---
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
On 3 Dec 2011, at 18:07, Andre Majorel wrote:
> On 2011-12-03 17:41 +0000, Stuart Dallas wrote:
>> On 3 Dec 2011, at 16:57, Andre Majorel wrote:
>>
>>> Hello all. I need to purge old records from application tables
>>> when a session expires. How do I register a callback with the
>>> end-of session-garbage collection system ?
>>> session_set_save_handler() lets me override the native garbage
>>> collection, not *add* to it, as far as I can tell.
>>
>> You would need to implement a complete session handler to add
>> your own functionality into the GC.
>
> Rats.
>
>> However, the fact that you want to do this begs the question,
>> why are you storing what sounds like session data in
>> application tables instead of storing them in the session?
>
> This "session data" is similar to a purchase basket. It
> references tuples from the static tables. If it's outside of the
> database, we lose the benefits of a relational DBMS.
Writing a session handler is pretty straightforward. I wrote about how to
implement one to use MySQL a while back which I'm sure you could easily adapt
to your needs.
http://stut.net/2008/07/20/mysql-sessions/
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 3 Dec 2011, at 16:46, Andreas wrote:
> Am 29.11.2011 23:54, schrieb Tamara Temple:
>> As I read it, the OP may be confusing application user logins and the
>> credentials used by the application to access the data base. Individual
>> application users should *NOT* have access directly to the data base by
>> having their individual credentials in the db access list. The application
>> should have a unique set of credentials for accessing the database, and the
>> only way users can gain access to the database should be through the
>> application. Do NOT store data base credentials anywhere in the session or
>> in cookies, either, as that can give people access to your database as well.
>
> Actually the OP is trying to figure out, why it is a good thing to have just
> one set of db credentials for the application instead of individual
> credentials for every user.
> The DBMS has a fine grained permission control system in place.
> The issue about thuis is I need to keep the users dbuser and password in a
> session or cookie because I need it for every connection to the DB.
>
> On the other hand a common way seems to be to check the users credentials and
> store just some kind of "LoggedIn = TRUE" and use the credentials of the
> application for queries.
> But this way I had to reinvent the access control system within the
> application.
It's highly unlikely that the access controls needed for any given application
match those that can be implemented with DB users without either a) making the
DB schema so complicated that it becomes unmaintainable, or b) making the
permissions so complicated that it becomes unmaintainable.
> I'm rather leaning to the 1'st way with individual credentials because I
> haven't seen convincing arguments against it, yet.
Think about it in terms of roles. As far as the database is concerned, access
roles are fairly course such as user or admin. Application roles are likely to
be more refined, such as visitor, subscriber, premium member, etc. It's quite
likely that the DB roles will require selective access to tables (e.g. admin
can write to everything but user can mainly only read), whereas user roles will
require selective access to rows (e.g. restricted access to premium content).
The other thing to bear in mind is that maintaining such a permission set with
database users is far more involved than maintaining it within the application
logic, and usually far less flexible.
> Right now we are talking about a web server that has just a very limited set
> of local users that might get the idea to snoop in /tmp for session files.
> AFAIK according to default settings the garbage collection runs not very
> ofthen on low frequented sites so stale session files could stay in /tmp for
> months. That is not very comfortable, though.
If you have untrusted local users then you should not be storing any sensitive
data on that machine. Period. Or any other machine to which that machine
connects. It also worth noting that even if you did go down this route you
don't need to store the DB credentials in the session. You must have retrieved
them from somewhere when the user logged in, so simply store a user identifier
in the session and use that to retrieve the DB access details.
You appear to be wanting to overcomplicate your application for no good reason
that I can see. Beyond the fact that you think it's duplicating functionality
(which it's not really), why would you want to do this?
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Andreas <maps...@gmx.net> wrote:
> Am 29.11.2011 23:54, schrieb Tamara Temple:
> > As I read it, the OP may be confusing application user logins and
> > the credentials used by the application to access the data
> > base. Individual application users should *NOT* have access directly
> > to the data base by having their individual credentials in the db
> > access list. The application should have a unique set of credentials
> > for accessing the database, and the only way users can gain access
> > to the database should be through the application. Do NOT store data
> > base credentials anywhere in the session or in cookies, either, as
> > that can give people access to your database as well.
>
> Actually the OP is trying to figure out, why it is a good thing to
> have just one set of db credentials for the application instead of
> individual credentials for every user.
> The DBMS has a fine grained permission control system in place.
> The issue about thuis is I need to keep the users dbuser and password
> in a session or cookie because I need it for every connection to the
> DB.
If you give every application user a unique set of database access
permissions, that means that any one of those users can access your data
base WITHOUT going through your application if they manage to get access
to your data base server. Is that clearer?
Your application's users should not be able to access the data base
directly. The application should be the thing to manage the data
base. You may want to have different data base credentials for different
user *roles* (plain, privileged, admin roles, etc), but to give *every*
application individual data base unique credentials is not only
unnecessary, but also a security risk.
--- End Message ---
--- Begin Message ---
To put it another way - your appl should control the access that a user
has - different screens/functions available depending upon the signon
credentials. The entire application's sql use (or all 'users' of the
database) should have a minimal number of user ids associated with it - both
to make programming simpler and to minimize the number of 'entry' points to
your database.
--- End Message ---
