Authentification fails with Space & é

Bug #332713 reported by yarrt on 2009-02-21
Affects Status Importance Assigned to Milestone
Armagetron Advanced

Bug Description

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
/login "Agent Zéro@forums"

He also tried the crazy tronners registry. Link to his profile (to contact him):

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

Related branches

yarrt (yarrt) wrote :

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) wrote :

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

Besides, it's a utf8-string :) 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) wrote :

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

I tried to login with Agent Zéro ( & 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 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) on 2009-02-22
Changed in armagetronad:
importance: Undecided → Low
Manuel Moos (z-man) wrote :

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:
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) wrote :

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

Changed in armagetronad:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers