If this configuration is done in XML:
http://mprabhat.wordpress.com/2012/07/20/spring-security-3-1-password-encoder-with-custom-database-and-jsf-2-0/,
it may be sufficient to provide two XML blocks, one using the deprecated
and one using the new, with the deprecated one commented-out. Then the
install guide would tell people to uncomment the one and comment the
other if they're upgrading from 5.0.x or earlier....?
Glen
On 01/27/2014 06:44 AM, Glen Mazza wrote:
If we have to, we have to--but how will people be able to upgrade from
5.0.x to 5.1 without everyone's password being lost and hence locked
out (i.e., if blogs.oracle.com tried this all users would be locked
out, right?) Perhaps we can support both algorithms in 5.1
(http://stackoverflow.com/a/17450276).
But if we have to break it, let's use moving forward the best
algorithm, from the above link the BCCrypt() one apparently (unless
you know otherwise). Also, we don't have to use Spring here if plain
Java offers corresponding libraries (less likely to deprecate).
Also, Greg, please answer this question I put in the comments (if you
know it), in case you missed it:
https://issues.apache.org/jira/browse/ROL-1795, we have the closing of
a JIRA issue (always a good thing :) on the line...
Glen
On 01/27/2014 05:23 AM, Greg Huber wrote:
Gentlemen,
The class
org.springframework.security.authentication.encoding.PasswordEncoder SHA
and MD5 in RollerContext has been depreciated, it can be replaced by
StandardPasswordEncoder(), BCryptPasswordEncoder() and NoOpPasswordEncoder.
The down side is the encryption is based on the username and password
(rather than just the password), so all passwords will need to be reset.
Any objections on doing this upgrade?
Cheers Greg.
