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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
