Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Localhost to Webhost - losing passwords


Reply

8 Posts   1114 Views

Avatar
socks

14 October 2009 at 9:13am Community Member, 190 Posts

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?

Avatar
dalesaurus

14 October 2009 at 12:44pm Community Member, 283 Posts

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?

Avatar
Willr

14 October 2009 at 1:21pm Forum Moderator, 5511 Posts

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

Avatar
dalesaurus

14 October 2009 at 3:28pm Community Member, 283 Posts

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.

Avatar
dalesaurus

15 October 2009 at 11:57am Community Member, 283 Posts

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.

Avatar
socks

15 October 2009 at 12:26pm Community Member, 190 Posts

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.

Avatar
dalesaurus

15 October 2009 at 12:47pm (Last edited: 15 October 2009 12:54pm), Community Member, 283 Posts

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.

Avatar
socks

15 October 2009 at 1:16pm Community Member, 190 Posts

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

Thanks again!