Hi Pavlos,
thx for your patch however its already "fixed" in upcomming 3.0-M1. It
use a new UsersRepository implementation called JPAUsersRepository which
allows to specify the algorithm to use.
At the moment it supports "MD5, SHA-256, SHA-512, NONE".
The previous used UsersRepository implementations are marked as
@Deprecated and will get removed in the future.
See:
http://svn.apache.org/viewvc/james/server/trunk/user-jpa/src/main/java/org/apache/james/user/jpa/JPAUsersRepository.java?view=markup
http://svn.apache.org/viewvc/james/server/trunk/user-jpa/src/main/java/org/apache/james/user/jpa/model/JPAUser.java?view=markup
Thx,
Norman
Ps: And thank you again for your contribution
Am 26.10.2010 09:44, schrieb Pavlos Georgiadis:
I just made a tiny patch (attached) that solves the issue described in
jira JAMES-334. The problem is just that james encodes the hash in
base64, while mysql and almost all other applications I know use hex
encoding.
This change would be fine for me, but it would be bad for existing
installations, as all existing hashes for all users in the user
repository would be unusable.
In order to avoid this I have thought of two different solutions:
1. To add an option in the userstore, where an administrator can specify
if he wants james to use bsae64 or hex encoding for hashes.
2. Create a script that can change all existing hashes from base64 to
hex encoding and forget base64 completely.
What would you choose? #1 is non intrusive as the default installation
option can be set to base64. #2 drops base64 completely and results in a
simpler auth mechanism.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
