Firstly the encryption of the database password was
causing some problems. When I printed out the
decrypted password (I added a bit of debug to the
SimpleCrypt class) I was getting "'&ма©" instead of
what I was expecting to see which was "admin". This is
why the system was failing as the passwords were not
matching! On a hunch I tried to use the password that
you had originally in the Lusid.properties. This
printed out fine, which meant that the system was
decrypting your password ok but not mine. I quickly
put your password thorough the encrypt servlet and the
encrypted password was not the same as the one from
your properties file. I guess this means your
encode/decodes are not working in sync with each other.
Logged In: YES
user_id=1025152
Adam: I cannot recreate the db encryption problem. It works
perfectly for me every time. Also, this used to work
perfectly every time at Liverpool so I'm a bit puzzled.
However, another user reported seeing a 'checksum error'
when trying to decrypt a password on a Mac.
Any further information would be warmly received.
Logged In: YES
user_id=1025152
Also, the following error seems common (but I cant recreate
it on any of our machines).
Using SAXparser: org.apache.xerces.parsers.SAXParser
lusid.LusidException: Encryption Checksum Failure
at lusid.crypt.SimpleCrypt.decode(SimpleCrypt.java:136)
at lusid.crypt.DBP.setDBPassword(DBP.java:38)
at lusid.LusidProperties.<init>(LusidProperties.java:965)
at lusid.Environment.<clinit>(Environment.java:114)
at lusid.Lusid.<init>(Lusid.java:206)
at lusid.LusidServlet.doGet(LusidServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
Logged In: YES
user_id=1025152
One can now disable DB password encryption. The installation
notes within the latest WAR explain how ot do this.