import db
Started by Sevarf2, Mar 14 2011 06:22 AM
6 replies to this topic
#1
Posted 14 March 2011 - 06:22 AM
I'm making a import script from my old db to PW db.
My problem is users password field. In my db passwords are already crypted. When i create a new pw user like '$user->pass = "password"' pw automatically create the md5 version. Is there a way to skip this process and save the password as i have in my db?
My problem is users password field. In my db passwords are already crypted. When i create a new pw user like '$user->pass = "password"' pw automatically create the md5 version. Is there a way to skip this process and save the password as i have in my db?
#2
Posted 14 March 2011 - 09:38 AM
The passwords are double salted, meaning the "salt" column with each user in the DB has to go along with the password. In addition, the $config->userAuthSalt at the bottom of your /site/config.php has to match between the two sites you are trying to share the passwords with.
For the users, you'll have to do this at the DB level rather than with the API. That's because ProcessWire randomizes the salt for that user every time you change the password. With the $config->userAuthSalt, you can just edit your site/config.php file to change that. Let me know if you need any help with either part.
The point of all this is better security. But you can disable all of the salting if it suits your needs better by setting $config->userAuthHashType to null (which will force it to do nothing but md5 hash). You would need to do this before installation, or use the API to reset the passwords of an existing site, as any passwords already in the users table would already be salted and thus non-functional until changed.
For the users, you'll have to do this at the DB level rather than with the API. That's because ProcessWire randomizes the salt for that user every time you change the password. With the $config->userAuthSalt, you can just edit your site/config.php file to change that. Let me know if you need any help with either part.
The point of all this is better security. But you can disable all of the salting if it suits your needs better by setting $config->userAuthHashType to null (which will force it to do nothing but md5 hash). You would need to do this before installation, or use the API to reset the passwords of an existing site, as any passwords already in the users table would already be salted and thus non-functional until changed.
#5
Posted 14 March 2011 - 10:40 AM
Will there be any limits at the new system? We sometimes have over 100 000 users that need to login.
#6
Posted 14 March 2011 - 10:50 AM
There won't be any limits, at least not any that aren't already present with pages. Though with 100k users... that's a lot.
It will likely be a good test to help us introduce new performance optimizations and ways of filtering them.
The existing user system was not designed to be scalable, as it was always seen as a temporary solution. Granted a temporary solution that suits the needs for most of the sites I work on. But it's not ideal if you have to deal with more than a couple dozen accounts.
Sevarf2 - how many accounts are you dealing with now?
The existing user system was not designed to be scalable, as it was always seen as a temporary solution. Granted a temporary solution that suits the needs for most of the sites I work on. But it's not ideal if you have to deal with more than a couple dozen accounts.
Sevarf2 - how many accounts are you dealing with now?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users













