On Saturday 08 December 2007, Oliver Jowett wrote:
> 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.
I didn't claim to solve the undetermined behaviour, I only said I maximized
the chances for the authentication to succeed. Read again.
> 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?
Well, it CANNOT be fixed for any encoding simply because of lack of support in
postgres. I thought about introducing a connection parameter, but the
community has to accept first my/a solution.
> 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..)
There's nothing spurious in my patch.
I haven't touched UnixCrypt, simply because there's nothing to be done about
it (not as a simple patch).
And the change in build.xml is a correction, check the file before posting
assumptions.
> 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's no specification simply because nothing special happens and "non-ASCII
authentication" is not even considered.
