Some Help/Information with vB Integration Please

[DarkScythe]

Originally Posted by Dismounted

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.

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.

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 >_<

[MoT3rror]

The hashing of the password and adding salt is done in the vBulletin user datamanager when I believe the pre_save() function is called or save().

[DarkScythe]

Oh!

If that's the case, that means that $userdata->set() does not actually enter the information in the database yet?

The hook I mentioned before came right before a pre_save() call.. If that's the case, then I can actually just stick my code there and grab password_md5 (or hash the plain password) to copy it over to EE, correct?

[MoT3rror]

I would probably just go for the password_md5. Then you can take this value over to EE and add more encryption and/or salt. It is not the best idea to store a plain text password anywhere.

[DarkScythe]

Oh, I'm not storing the password as plain text

I just needed to know where I could grab the password at all before vB's salt got added to it. EE does not support salts, it only supports plain MD5 or plain SHA1 hashing (out of the box at least.) This is the reason I've been trying to look for it everywhere, I need to either copy the MD5 hash over, or find a way to SHA1 hash it and copy that over. Since vB's Javascript auto-hash kills my attempts to SHA1-hash the password, I'll have to use the MD5 instead. If Javascript is disabled though, it won't be pre-hashed, and password_md5 will be empty - which is when I would need to get the plain text password and hash it myself.

Thanks for the tip on pre_save though, I'll try to look that up and see if I can follow that a little more to figure out where the database calls are at.

[MoT3rror]

The pre_save functions pretty much makes all the checks and gives you errors in the $userdatamanager->errors as a array. The database call can be found in save().

[DarkScythe]

Thanks for the tips!

Kind of late now though.. I'll have to look through the code tomorrow morning.
If you have any more tips/tricks/advice that may help though, I'd appreciate it.

I'd need to grab username/password/email/salt/birthdate during registration, then password/email wherever they can be changed. I don't think users can change their username or birthdates, so that's not a problem. I'm not sure about the salt though, does that change?

Thanks again!

[MoT3rror]

You will have to fetch the salt after the save function. The birthday of the user can be changed by the user I believe.