--Scott thanks - preparedStatement.unwrap() did the job for using
OraclePreparedStatement but given the JavaDoc warning about the cost of calling
unwrap() we are have to make a policy decision to only use
OraclePreparedStatement where we really need a feature such as named parameters
I am still migrating from 2 to 4.00.22
Old logins are not working and it seems there is an acknowledged difference
between the implementations of the algorithm between resin 2& 4.
eg: password= TzW4CeGhlPNePIaacjYO6w== dbPassword(created under resin 2)=
TzW4CeGhlPNePIaacjYODr digest= MD5-base64
It seems the difference is only for the last few characters.
Presumably if the difference in the implementation is just to do with the
length of the generated string and/or padding then this could be relied upon.
If I implement a scheme to replace the correct encodings as users login can I
rely on an assumption that the first 15 characters will match for the same
password under each implementation to provide a good enough match that triggers
an update of the database with the full/correct encoding?
I have seen reference in forums to a digest option "old-encoding", is this
If it is how would I amend the following to get a copy of the old digest value?
PasswordDigest digest = new PasswordDigest();
digest.setAlgorithm("MD5"); // Must match resin.conf
digest.setFormat("base64"); // Must match resin.conf
aPasswordDigest = digest.getPasswordDigest(userNameValue,
If I can't rely 100% on the similarity of the first chars of the encoded
password to identify valid logins and update the encoding I would like to be
able to check the dbpassword against both encodings and update the db with the
correct encoding as necessary.
Asking users for passwords is not an option and wholesale resetting of
passwords is not ideal from a customer service perspective.
Thanks in advance for any clarification.
tel 0845 230 9803
Athene Systems Limited
Registered in England and Wales No. 3156080
resin-interest mailing list