$config->httpHosts and passwords

[yellowled]

I developed a client's site using a temporary domain. Over the weekend, the “real” domain(s) were added to the webspace, so I added them to $config->httpHosts in /site/config.php and removed the temporary domain there.

As a result, all backend logins “forgot” their passwords. That's not a biggie in this case since I have the “Forgot password” module installed, but it's still something that alerted me since I don't see the connection there. I suppose it might even be a bug? (Using 2.4 here.)

Anybody have an idea if there actually is a connection here (sessions? cookies?) between httpHosts and passwords?

[MadeMyDay]

Same here. Since 2.4. this happened two times, but I can see no pattern. Sometimes it works, sometimes not.

[yellowled]

I should maybe add that this is a site where I had to use $config->sessionFingerprint = false; in /site/config.php to avoid being logged out of the backend all the time.

[ryan]

HTTP hosts, sessions, cookies don't come into play with passwords. Some other factor must be at play during that migration. Of course, a change in hostname will kill active sessions, since the session is tied to the HTTP host. But that's no different than if you just logged out. What can affect passwords is the PHP version and what capabilities it has with regards to encryption support. If you are running PHP 5.3.8 or newer (our current minimum requirement) then it won't be a factor unless you are moving to a PHP installation where the administrator has disabled some of PHP's encryption functions (which would be unusual and rather bad from a security standpoint). 

I kind of doubt that any of the above are it. What is more likely is a change to the $config->userAuthSalt (which appears at the bottom of your /site/config.php file). That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken. Is it possible you changed out the /site/config.php or even accidentally modified the value of userAuthSalt?

[MadeMyDay]

I am not sure that the problem are passwords only. I still have one installation where I can only login via the development sub domain and not with the live domain. This is exact the same installation in the same folder with both domains pointing to it, http hosts are both set. The error message also is not "wrong password" but this one:

Saying "Login failed".

[ryan]

PW isn't going to differentiate between wrong password and failed login. If it gave a different message depending on whether the error was with username or password, then the login form could be used as a tool for discovering usernames by dictionary attack (which would be undesirable from a security standpoint). 

Do your development subdomain and live domains use different /site/config.php files? Check if there are any differences in the $config->userAuthSalt line. Are there any differences in the PHP versions?

While in your /site/config.php file check that you have a $config->httpHosts = array('domain.com', 'dev.domain.com', 'www.domain.com'); line in there (accounting for all possible hostnames). This isn't involved with passwords, but it can cause issues that might potentially have that appearance if not configured properly.

[yellowled]

What can affect passwords is the PHP version and what capabilities it has with regards to encryption support. […]

Is it possible you changed out the /site/config.php or even accidentally modified the value of userAuthSalt?

I have done nothing with /site/config.php in this particular installation but edit $config->httpHosts over FTP using a text editor. That doesn't seem as if it would change the userAuthSalt (although it's of course always possible that some weird copy & paste foo happened there).

It's kind of hard to diagnose since this is a project which has run on the temporary domain for quite some time, and unfortunately, there's no version control here, so I can't easily check for changes in that file.

I do, however, recall switching the PHP version after the installation (I think from 5.2.4 to 5.3.x or 5.4.x), and here's the thing – for the new domains, the PHP version has been switched back to 5.2.x according to the web hoster's admin interface. I am, however, going to have to consult their support to see if these actually are valid here (the admin interface is kind of confusing).

[yellowled]

I do, however, recall switching the PHP version after the installation (I think from 5.2.4 to 5.3.x or 5.4.x), and here's the thing – for the new domains, the PHP version has been switched back to 5.2.x according to the web hoster's admin interface. I am, however, going to have to consult their support to see if these actually are valid here (the admin interface is kind of confusing).

That was actually valid, so I just switched both domains back to 5.3.19 and logged into the backend to make sure that it still works. After logging in, the backend gives me a message saying (paraphrasing here since the backend is in German) that the password system has been updated and advising me to change the password to update my account …?

[teppo]

@yellowled: that sounds just about right. ProcessWire uses Blowfish algorithm for passwords whenever possible (PHP 5.3.0 onwards) and a stronger version of it if PHP version is 5.3.7 or newer.

Passwords created in earlier versions will get the update notice and there's at least a chance of problems arising if you go from PHP 5.3.0-5.3.6 to 5.3.7 or newer -- or vice versa.

If I'm reading you correctly and the same site can be accessed with multiple PHP versions, I'd assume there being quite a bit of weirdness. That's a problematic situation in many ways, and this is just one of those

[yellowled]

If I'm reading you correctly and the same site can be accessed with multiple PHP versions, I'd assume there being quite a bit of weirdness.

It's now switched to one PHP version (5.3.19) for both domains and seems to work just fine now. The weird thing is actually that it did seem to wok okay on 5.2.x, but then again, I haven't really worked with it while that was active.

Thanks for clearing that up.