For testing, I migrated our journal from our production 2.1.1 installation to the 2.2.0cvs release (I think I most recently updated last week..).
I believe the default encryption format for passwords has changed from 'md5' to 'sha1', in config.inc.php.
I didn't see this in the release notes anywhere, so heads up to those attempting such a migration. (It took me a bit of time and "error_log" debugging to figure out what was happening.) Sorry if I missed this somewhere.
Actually, it would nice if Validation::encryptCredentials would try whichever setting is specified, and then just check the other in case of a bad match -- there are only two choices, so it could catch this problem easily and warn in my php log. Alternatively, if you don't want to check md5 when sha1 is specified *and* vice-versa (with more encryption options, this could get unwieldy!), at least try the config.inc.php specified value, and (IF there's a failure AND the value is not the code specified default (md5) ) THEN (check md5). Does that make sense?
Also, it looks like there is duplication (albeit in a different order) between Validation::login and Validation::checkCredentials. login() calls encryptCredentials() directly after some special casing for old email addresses (OJS1?).. but reading checkCredentials, it seems to have most of that functionality (not the special casing, however). It feels to me like login() should be calling checkCredentials() rather than duplicating the work of checkCredentials() itself. Am I off base here?
Thanks for the great work!