Authentification fails with Space & é

from IRC:
(22.02.2009 00:05:26) dlh: se_EscapeName( "Agent Zéro" ) => Agent\_Z%C3%A9r
(00:05:30) dlh: :|
(00:05:59) dlh: off by one error maybe?
(00:10:48) dlh: so, both se_EscapeName() and se_UnEscapeName() cut off the last character
(00:19:32) joda_bot: I guess the "\" of the _ is not accounted for

I can't reproduce dlh's observed behavior. What were the exact test conditions?

Besides, it's a utf8-string :) 0.2.8.1 uses latin1 strings, and they SHOULD be encoded correctly with non-ascii characters escaped to hex. Now, the current trunk implementation of se_(Un)Escape clearly needs adaption to utf8. Or not, it's not actually used for the auth process and the only important thing is that it's reversible :) (And yeah, we want the escaped names not to change from one version to the next, if possible.)

The really buggy function is nKrawall::EncodeString, it's using a signed char to encode non-ascii stuff to hex. That has been fixed on 0.2.8 and works with the reference auth implementation.

I don't know if the function dlh tested is used at all for authentification.

I tried to login with Agent Zéro (0.2.8.3_beta1 & 0.2.8.2.1) both a login name like below.

(00:58:22) joda_bot: ct|kyle: brb, I'll try to auth with his name, and see if I get wrong password or wrong user
(00:58:38) joda_bot: if you can monitor authentification that data might prove helpful
(00:59:18) ct|kyle: yes i can look at the @ct
(01:01:24) ct|kyle: joda_bot: UNKNOWN_USER Agent Z?FFFFE9ro
(01:01:48) joda_bot: yeah that I got on the client too
(01:01:51) ct|kyle: joda_bot: same
(01:02:06) joda_bot: wait I'll try a 0.2.8.2.1 client
(01:02:18) ct|kyle: somwhow ?FFFFE9 needs converted to é

From my perspective anything not using a "sane" charset is a bug. The escape is not UTF-8 nor another valid charset escape I know. A valid unicode escape should have 00 instead FF bytes (AFAIK?). Is this the "signed char problem" you describe?

My view:
I suggest that a certain (universal?) charset is used for the authentification process - otherwise the protocol should send the charset used. Note just escaping bytes with URLEncode won't fix things either as the auth-server then still does not know how to convert those bytes to characters. URLEncode with a specific charset should work.

Yeah, it's the signed char problem :) The buggy code takes the char as signed, blows it up to an int, and prints that as hex, with obviously wrong results (it seems to convert it back to unsigned, but printing it as signed would be just as wrong). And yes, we need a definite encoding, preferably utf8 in the long run. But I posted about a problem with that here: http://forums.armagetronad.net/viewtopic.php?t=19064
current authorities are likely to expect latin1. The forum authority does, anyway. This close to a release we want to call stable, it's not a good time to break them. There's no standardized way to pass encoding info in URLs (though adding 'encoding=<encoding>' would certainly do the job).

Both trunk and 0.2.8 now use utf8 consistently for authentication stuff. Authorities likely need adaption.