Re: JDBC driver patch for non-ASCII users

sulfinu@gmail.com wrote:

> Without it, the behaviour of the current
> JDBC driver is UNDETERMINED in a non-ASCII environment (for disbelievers:
> check the javadoc for String.getBytes() and String.getBytes(String)).

BTW, your patch does not actually change this, you are still using
String.getBytes(String) so if you pass a username / database name /
password that is not representable in the encoding you're using for
authentication, you lose.

We can't use CharsetEncoder in pre-1.4 environments, so I don't see a
way of getting strictly correct behaviour here.

In practice, the behaviour of getBytes(String) seems fairly predictable,
you just get "?" back for unmappable characters, which of course doesn't
work for authentication but at least it doesn't go and set your cat on
fire ;-)

> What I proposed below is for the driver to use the environment's encoding in
> an attempt to match the encoding used at server side to store the user,
> password and database strings, provided that this local encoding is an ASCII
> extension. If it's not, the driver uses the UTF-8 encoding, thus allowing for
> a setup where things can work regardless of the environment (specifically,
> the database cluster should be (re)created with the UTF-8 encoding).

I don't particularly like this approach because it only solves the
problem for some encodings. Search the JDBC list archives and you'll see
we have had the same problem in the past reported for GBK-encoded
usernames, and I believe that encoding is not a superset of ASCII. If
we're going to mess around with charsets during authentication I'd like
to see all encodings fixed. In that particular case a new URL parameter
was suggested but I don't think it ever got into the main code. Perhaps
you can follow up on that approach?

Also, your patch appears to have a number of unnecessary changes in it
(e.g. why did you change the encoding used for the password salt, or the
results of UnixCrypt? and there's a spurious change to build.xml too..)

I would also be a lot happier if the protocol specification docs were
updated to reflect whatever the current "approved" way of doing
non-ASCII authentication info is before the driver started making
assumptions about it. (There are in fact 3rd party apps out there that
implement the server side of the protocol..)

-O