You have to take in account if people change email addresses, etc. So the best way (IMO) would be to hook into the user data manager.
I'm aware of this - Within EE and phpBB, I have laid out database calls in several files where these changes happen, but the biggest one to deal with first is the registration, and is why I'm focusing on this. Also, data managers are for putting data into vB's databases, as I've been told, and I don't think it will suit my needs in doing the complete opposite - pulling data off it and putting it into another database.
Quote:
Originally Posted by Dismounted
If "password_md5" is empty, it does mean JS was disabled and $vbulletin->GPC['password'] contains the unhashed password. It is still hashed and salted server-side.
This is interesting.. When does it get hashed if JS is otherwise disabled? Certainly, the unhashed password field can't remain in its unhashed state by the time the $userdata->set call is made, unless that call also has a hidden function to automatically hash as well as store at once.
Quote:
Originally Posted by Dismounted
$vbulletin->GPC['password_md5'] during registration will be the single md5-hashed password.
Similar to the question above, when does the salt get added to this hash (and when does the salt itself get entered into the database?) The only other time I believe I see the php hashing is in functions_login.php that I quoted earlier, but I don't see the registration page even requiring that file.
Am I just overlooking something very obvious here?
Thanks for all the help >_<
07-30-2008, 01:15 PM
So the best way (IMO) would be to hook into the user data manager.
Threaded Mode