Okay, a little more digging later, and the plot thickens some:
I'm throwing an exception at line 170 in Connection.java, which suggests
that the response from the server is 'E'. That in and of itself is not
too interesting. What *is* interesting is that I have been denied access
even before the server asks for a password (the code to deal with that
is in lines 200-215 of the same method). This, to me, suggests that
something isn't happening right with regards the protocol matching in
the JDBC client. Or that I'm stupid, I'm willing to accept either
answer.
However, based on that, I would guess that the crypt() problem isn't it.
As for the postmaster log file, there is nothing special in there:
verify_password: password mismatch for 'XXXX'.
Password authentication failed for user 'XXXX'
The stack trace is below. Under that is some commentary on the initial
response I received (thank you!)
java.sql.SQLException: Password authentication failed for user 'XXXX'
at org.postgresql.Connection.openConnection(Connection.java:170)
at org.postgresql.Driver.connect(Driver.java:122)
at java.sql.DriverManager.getConnection(DriverManager.java:517)
at java.sql.DriverManager.getConnection(DriverManager.java:177)
[...]
Peter Eisentraut writes:
> > The JDBC driver claims "Password authentication failed for
> > user 'XXXX'"
>
> AFAIK, OpenBSD uses MD5 as the default crypt() algorithm,
> whereas the JDBC
> driver assumes the traditional DES-like method. I suppose you have to
> hack either one to do otherwise.
Uhm... would that then mean that if I was on an OpenBSD machine as a
client (i.e. just running psql), I would be unable (at least without
massaging some code) to access a postgres instance on, say, a Solaris
box? That sounds *very* fishy to me.
Any chance we can have a standardized hashing function built into the
code? If you can't guarantee implementation at the OS level (or you make
false assumptions), there seems to be no other truly suitable
alternative.
Thanks,
Paul Hart
