Jim Lucas <lists@xxxxxxxxx> wrote: > On 11/29/2011 6:28 AM, Al wrote: > > On 11/29/2011 7:40 AM, Nilesh Govindarajan wrote: > >> On Tue 29 Nov 2011 01:34:08 PM IST, Andreas wrote: > >>> Hi, > >>> > >>> is there a most advisable way to store db-passwords of an open > >>> user-session? > >>> As far as I get it, a common login strategy is to let the user login > >>> by name&password, check it, store a login=TRUE as php-session variable > >>> and later use a common dbuser+pw to query data provided "login" is TRUE. > >>> > >>> This way one wouldn't have to store the users pw or actually the user > >>> wouldn't have a real db-account but rather an application account. > >>> > >>> Is this really better or equal than using real db-accounts? > >>> > >>> Should I rather store the db-credentials in a session or cookies? > >>> > >>> Session is vulnerable as any host-user could look into /tmp. > >>> This would generally be a trusted few though. > >>> > >>> On the other hand cookies could be manipulated by the user or at least > >>> be spied upon on the way between user and web-host every time the > >>> credentials are needed for a query. > >>> > >> > >> What exactly do you mean by db-account? > >> I didn't understand your question, but this is what I do in my > >> applications- When the user submits the login form, validate POST data > >> (for mischievous stuff) and check if username& password query works > >> out successfully. If it does, store a session variable login=true and > >> let the user work on the private parts of the site. > >> The cookie essentially, contains just the session id. I never use > >> cookies to store data, only sessions. > >> I also add ip and user-agent filtering to my auth systems. > >> > > > > Sounds like $_SESSION buffer is what you need. I use the buffer extensively in > > most of my designs. > > > > > > > > It seems to me that the OP isn't asking where to store it, s/he is asking what > to store. > > I would suggest storing only the SESSION ID in the cookies. In most setups, > this is done automatically. > > Then in the sessions file place only the information that will allow you to > identify the individual in question. > > In some cases, I have seen were the first step is followed above, but then > rather the just the identifiable information in the session, one would grab all > the account details and place this information in the session instead. The only > benefit I see here is the within future page requests, you don't have to hit the > DB for the account details, they are in a session file that you already had to > load into memory. The drawback to this approach is that all the account details > are in a file on the file system that could (in some situations) be read by > other system user accounts. 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
