FrancisChung Posted September 4, 2015 Share Posted September 4, 2015 Hi there, I'm developing locally on my laptop and we have a testing server where I deploy via rsynch + running a DB Dump script. (Exported via MySQLWorkbench) I've noticed that the admin password becomes invalid every time a DB Dump script is run on the server. Is this possibly because there's a hash and/or salt stored alongside the password and my local one is not valid on the server?Are there better practices of synching between my local Processwire and the server instance to prevent the admin password being invalidated? Link to comment Share on other sites More sharing options...
LostKobrakai Posted September 4, 2015 Share Posted September 4, 2015 This should normally work ok, but to answer the question, the password salt is in the site/config.php and nowhere else. Link to comment Share on other sites More sharing options...
FrancisChung Posted September 4, 2015 Author Share Posted September 4, 2015 Perhaps I should resynch the config.php files between the 2 machines and try again. Thanks for the answer, LostKobrakai Link to comment Share on other sites More sharing options...
bigbeee Posted April 5, 2016 Share Posted April 5, 2016 I have the same issue after DB syncing, i got it that salt in the config is the issue but as said several times its known that passwords will not work anymore after site migration. As far as i can say its not about the salt because nobody changes the salt for the migration. It wouldnt even be that bad if the user account data wouldnt be in the page table which of course has to be deployed if i add changes to the page. I deploy sometimes 10 times a day at least to staging areas and i am tired of reseting the passwords again and again. Isnt there any way to disable this? If a user changes his password by himself i will never be able to deploy without knowing his password? Link to comment Share on other sites More sharing options...
LostKobrakai Posted April 5, 2016 Share Posted April 5, 2016 If the user salt is correctly deployed and your fields_pass table is also correctly moved there should be no problems. The only issue I can imagine is that one of your environments might support blowfish encryption and the other one doesn't, which would result in different hashing behaviors. A few words about your rant about users being part of the pages table: If you have just about any amount of user-generated / user-changeable content you cannot overwrite the db just with a sql dump. You'll need to go different ways if you need to deploy (possibly automatically) your database changes with a staging/live environment. Therefore it shouldn't matter that much if users are pages as well or not. 1 Link to comment Share on other sites More sharing options...
bigbeee Posted April 5, 2016 Share Posted April 5, 2016 The Blowfish encryption is an interesting detail, will check that. Would make sense. Of course i need to sync in both directions but if it would be a separate table i would simply exclude them. Link to comment Share on other sites More sharing options...
bigbeee Posted April 7, 2016 Share Posted April 7, 2016 Migrated my dev environment from MAMP to vagrant box and the issue doesnt happen anymore. So you are right that the reason is an environment detail, in my case of MAMP. Link to comment Share on other sites More sharing options...
ank Posted August 6, 2018 Share Posted August 6, 2018 I have the same problem with Mamp. Has someone already a solution to make it work with mamp ? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now