I'm on my third SS site and getting ready to go live. On the first two, I couldn't login after uploading the database to the host and if I remember correctly, the other two users I set up weren't working either.

I know I can hard code a user and password in the _config file which by-passes the issue for the first time I load to a live server. But what if there was a disaster and I had to reload the database from a backup with 80+ users or if I go thru the trouble of setting users and passwords before I upload. Am I doing wrong when dumping the database?

I had this happen to me when moving from local -> dev server before. I was not able to fix it and had to re-do all user permissions, but thankfully it was only 3 of them.

Can anyone confirm a migration procedure or that straight copying the DB with mysqldump that should work?

It could be because the hashes are different on your live server. See this ticket for more information - http://open.silverstripe.com/ticket/3004

Ahh...where is the jawdrop icon?

I'll give the suggestion of removing the base_convert pack on Security.php:859 a shot and report back, socks.

I have confirmed that the fix suggested above works, to move data from DB to DB.

Security.php:859

//		$password = substr(base_convert($password, 16, 36), 0, 64);
		$password = substr($password, 0, 64);

This will make your passwords portable from DB to DB, however all your existing passwords will no longer work. My suggestion would be sending out a mass email prompting people to use the Lost Password function, maybe add a note to your Security_login.ss template telling people to do so.

I have to say I'm disappointed that this critical issue is a year old as it affects so many people. Not sure if it affects everyone or just depends on localhost & webhost configuration.

So, if I dump the database from the webhost and then have to restore from that backup, does the password hash corruption still exist? Or is it just a dump from a different server (in this case, localhost) that's causing the issue?

Thanks willr for pointing us to the related information.

Thanks dalesaurus for following up. I guess that fix makes me nervous (since I don't know enough to speculate about possible repercussions). And if I forget about it and apply the next update (overwriting the patch), will all the passwords be corrupted?

Thanks for your suggestion about the Lost Password, I didn't think about that as a possible solution.

Per the ticket it happens when

• 1. A User's password is changed or set on Server A
  
• 2a. You move your password tables to apache+mysql Server B
  
• -OR-
  
• 2b. You have apache Server B which is linked to the same DB as apache Server A
  
• 3. User log in from Server B fails
  

Step 3 happens if Server B is different from Server A in ANY WAY (php version/arch/OS type/etc.)
They will not return the same base_convert value all the way through 64 bits due to the floating point pecision involved: http://www.php.net/manual/en/language.types.float.php All your DB is doing is storing the value, its PHP on the webserver that can't competently compare the password.

As freakout suggested in the ticket, it will be the same for at least the first 9 or so characters.

So if your users are not changing passwords or creating accounts on you Dev system, you will be fine. Any accounts that do will need to use the lost password function. In this situation the impact is limited to developers/internal folks.

However if you have a catastrophic failure and need to switch webservers everyone will need to use lost password (unless you apply one of the fixes outlined here). It certainly is scary for anyone who wants to use SS for like...business. I'm also a bit stunned that something like this has been allowed to fly under the radar for FIXING.

That clarifies the issue for me. I think I'll stick to not entering in usernames and password on Dev versions.

Thanks again!