Re: Change User on a pconnect

On Sat, 6 Nov 1999, Rasmus Lerdorf wrote: > That would work. Then the next question is whether we need to keep the > username/password stored in the hash up to date. ie. if the user calls > the user-level mysql_change_user() function, we should probably modify the > info in the hashed structure to reflect the currently authenticated user > on that link. yep, that would be needed. > > By the way, what prevents someone from guessing a persistent link > identifier and using it without authenticating on it right now? I don't > see the code that prevents this, but I should take a closer look. I'll > play with this stuff this afternoon. I'll probably wait until after > 3.0.13/4.0RC2 before I commit it though to avoid last-second breakage. hmm, in PHP 4 the link would be a resource and only c-modules can create resources. in PHP 3 this could be a problem, and thinking a bit longer .... i believe every script could guess a link-number - that's not good. tc > > -Rasmus > > On Sat, 6 Nov 1999, Andi Gutmans wrote: > > > I think the hash key would have to be just the hostname, and the structure > > saved in the hash would need to contain the MySQL link, username & > > password. The MySQL module would then lookup the connection by hostname and > > would compare the username/password to the ones stored in the hash's value. > > If they are different, it would then do a change_user and update the hashed > > information. > > > > What do you think? > > > > Andi > > > > At 04:32 PM 11/5/99 -0500, Rasmus Lerdorf wrote: > > >I just added mysql_change_user() to the PHP 3 tree, mostly because someone > > >asked me for it. However, the idea behind the function, and why it was > > >added to MySQL recently was to allow us to maintain a pconnect across > > >different user mysql user ids. This would mean that if we are talking to > > >MySQL-3.23.3 or higher, we would not store the username and password in > > >the hashed_details, but instead just do a change_user. > > > > > >However, I don't want to slow down the pconnect process here with a > > >change_user call that might not be needed. So perhaps we should still > > >store the username/password in hashed_details and let pconnect work the > > >way it has always worked, but have a different puserconnect function or > > >something like that which would do an automatic change_user on a > > >persistent connection and if it fails to authenticate it would not return > > >the connection link identifier to prevent someone from hijacking somebody > > >else's persistent link. > > > > > >Comments? > > > > > >-Rasmus > > > > > > > > >-- > > >PHP Development Mailing List > > ><http://www.php.net/> > > >To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > > >For additional commands, e-mail: php-dev-help@lists.php.net > > >To contact the list administrators, e-mail: php-list-admin@lists.php.net > > > > --- > > Andi Gutmans <andi@zend.com> > > http://www.zend.com/ > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > > For additional commands, e-mail: php-dev-help@lists.php.net > > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany