Authentification fails with Space & é

[yarrt]

A player named "Agent Zéro" can't login inside ArmagetronAd. I think it might be an authentification issue with é or the " " (space) inside his name ?

He can't auth with
/login "Agent Zéro"@forums
or
/login "Agent Zéro@forums"

He also tried the crazy tronners registry. Link to his profile (to contact him):
http://forums.armagetronad.net/profile.php?mode=viewprofile&u=3192

My guess: forums.armagetronad.net uses UTF-8 to store names and Armagetron sends characters as ASCII then the user look up will fail.

[yarrt (yarrt)]

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

[Manuel Moos (z-man)]

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.

[yarrt (yarrt)]

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.

[Manuel Moos (z-man)]

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).

[Manuel Moos (z-man)]

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