I see some other posts here mentioning login problems following site updates to the most recent v1.4 release. I have also noted the responses denying any changes to zenphoto itself that might cause such a problem. Nevertheless, the same thing happened to me when I ran the setup to update from version 1.3.1.2 to version 1.4.

I was able to log in as the administrator both prior to the version update and for initiating the upgrade process. Following that process, however, I was locked out. In fact, the reason appears to be a change made during the upgrade to the extra_auth_hash_text entry in the zp_options table. I certainly didn't change it myself.

Here are partial direct dB exports of the zp_options table before and after upgrading. Note the change in the entry for extra_auth_hash_text from `& amp;` to `&`

Before upgrade (v1.3.1.2):

`(1, 0, 'zenphoto_release', '5831', NULL),`
`(2, 0, 'extra_auth_hash_text', 'T^Y|O9upranHBI6F#4Z?VPlMxSA& amp;,+', NULL),`
`(3, 0, 'libauth_version', '2', NULL),`

After upgrade (v1.4)

`(1, 0, 'zenphoto_release', '6454', NULL),`
`(2, 0, 'extra_auth_hash_text', 'T^Y|O9upranHBI6F#4Z?VPlMxSA&,+', NULL),`
`(3, 0, 'libauth_version', '3', NULL),`

NOTE: The space in & amp; is because backticks here won't let it stand intact as it actually was in the database.

Interesting. Still, I do not know how that can happen. Only if somehow the characterset has changed (and that also causes that character to change). What charcter set is your database?
I really did not even know there are two representations of "&".

All that Zenphoto does is fetch the string from the database, place and place it into the input field for that option. Then when you save options it would get written back to the database. Where in that process the character could get changed is the question.

My database is set for UTF-8 as its default character set, unchanged between the two zenphoto version installs. However, my PHP sub-version has been updated during that period for security reasons, but without changing its php.ini settings

I really don't have any idea about how it might happen if there has been no change in the application code or its string manipulation. I only know that it did happen to me and thought I'd pass it along in case it might provide a clue to what appears to be an occasional annoyance. It would be rare, of couse, if it only occurs when there just happens to be an ampersand in the hash.

Does (or did) the code use the PHP htmlspecialchars() function at all?

@sbillard: For `&` there is `&` (HTML entity) and `&` (Unicode within HTML). Not sure if that helps though..

Sorry that I can't really add much to my observations above. I've looked at the coding changes in the lib-auth.php file and I see that the two zenphoto versions differ quite substantially in their handling of extra_auth_hash_text. Beyond that, however, I'm afraid I'm lost except to suggest that a HTML special character (& amp in place of the regular ampersand character (&) would affect the value returned for any comparison purpose, including authentication of course.

Again, having raised the issue, I apologise for being unable to offer any more specific thoughts on a possible answer to it, but I'm afraid I have to leave that to you guys. Good luck pinning it down.

Yes, all input fileds are html encoded as required for validation, so it would have used. That could be impacted by the "interpretation" of `&` by the browser or PHP.

I guess we will take the '&' out of the candidate character list just incase.

BTW, not exactly sure what the "differ quitye substantially in their handling of extra_auth_text" is all about. Not any change at all in that. Only a relocation of where the default options are created into the class.

I just did a straitforward comparison of the lib-auth.php files of the two versions and noted what appeared to be some quite large internal coding differences, including some in the functions that handle the extra_auth_hash_text dB entry. That's all. What ultimate significance (if any) those changes may have in this or any other specific context I made no attempt to assess. If you say they're insignificant, that's fine with me. Just trying to be as helpful as I'm able to be in the circumstances. Probably not much, I suppose.

Nevertheless, in the same effort, perhaps I should also point out that the ampersand (&) is not the only character that could potentially be involved if, as you say, all of the data input fields are being html encoded. For example, the $salt variable that is used in the migrateAuth() function of the older version and in the Zenphoto_Authority() function of the newer one contains quite a few such characters as specified by the W3C standards. Their complete listing is available at http://www.w3.org/MarkUp/html-spec/html-spec_13.html

Your comparison must have been pretty superficial. All that was done was to relocate code. No changes to the code at all.

And your reference is a bit overboard. Just because something can be encoded does not make it a requirement. A better reference would be http://us3.php.net/manual/en/function.htmlspecialchars.php

Besides, the round trip conversions *should* be semetric. That is if one encodes an "&" into "&amp'" it should then decode back to the same "&".

I don't understand why you are being so defensive. I've simply noticed a problem in my own case that seems as if it might correspond with some others that have been posted. I therefore figured it might be helpful to describe here what I was able to discover about it myself. Yes, I agree, it's superficial. I made no attempt to be profound.

By "starting fresh", I've been able to deal with my own situation. So ignore my input completely if you wish. It was you, not I, however, who said that "all input fileds are html encoded as required for validation." That's a bit unusual for certain types of dB field inputs, I think. But I was really just trying to point out that, in that case, it could involve more that the ampersand (&) alone. You had also said: "I really did not even know there are two representations of '&'."

Sheesh! What a grouch! Forget it!