In the abscence of a response from tech support I've done some further digging around. It appears that the passwords should be stored in the database using md5 encryption when using the built in authentication.
Except that they aren't - as a result the user types the password into the login box and it automatically fails because this is md5'd and the compared to the stored password in the database (which isn't).
The 'sometimes works, sometimes doesnt' behaviour comes from the fact that when installing ReviewPost, the password cookie is set when the Admin user is set up. As long as you don't log out and the cookie doesn't expire you can still access all of the admin functions.
Once the cookie expires then you can't log back in . . . .
So, the next problem - I've imported in 12,000+ users, created passwords for them (and md5'd) them and set their usergroup but none of them can log in.
Any ideas why ?
Last edited by mtbwales; June 14th, 2005 at 08:08 AM.
Well I have seen this happen about 1 in a 50 installs with the password being passed plain not md5 although looking at the coding there is no explanation why.
All you can do for that admin login is change it manually or use the forgot password link. This only seems to be an install quirk sometimes as regular users register fine.
As far as your imported users my honest answer is I can only speculate. You imported users meaning you wrote some custom script to throw users into the reviewpost database. There could be several things wrong in this scenerio.
Are the stored passwords md5?
Where the usernames stored correctly in the database?
I then did an update to convert all passwords to md5 like this:
UPDATE rp_users SET password=md5(password);
All passwords are stored as md5 versions, the usernames are correct and I've assigned a usergroup of 4. Is anything else used to authenticate a user such as an IP, registration date etc because that's all I can think of that's missing.
Obviously the issue here is the authentication of the password from what I am seeing. The only way to truly set things right at this point I would say is make a random password md5 like password and issue a mysql statement to update password to this password minus the admin user
The users will get their password when I mail out my next newsletter to them from my main website MTB-Wales.com. Their username is the sam on the main site. NB: the 'password' in the SQL statement above is random !
The only way to truly set things right at this point I would say is make a random password md5 like password and issue a mysql statement to update password to this password minus the admin user
That's what I did - currnetly only the admin user can log in
Figured it out - initially I created random passwords and imported these into the rp_users table. I then did an update on each converting it to an md5 using the MySQL MD5 function. This yields a different MD5 hash to the PHP one.
In practice this means that although the users password is entered during the login process, and it's converted to the MD5 version by PHP, it won't match the MySQL'd MD5 version in the database. So the user can't log in !
i was having this problem forever, i found the problem is that you might have fogotten to put your tables prefix into the settings. i forgot this everytime and i had endless problems and then i finally noticed that box in the setup and put the right data and was good to go problem free.
Last edited by ncg; June 15th, 2005 at 09:15 PM.
Reason: fixed it