#34 being so relaxed regarding usernames causes bugs

[Lee Harr]

Originally reported on Google Code with ID 64
``` What steps will reproduce the problem?

1. create one user called "ola" 2. create another user called "ol^Fa" (where ^F is actually a Control+F 3. login both in the talker

What is the expected output? What do you see instead?

Since we accepted the two different usernames, both can act as users. Problem is, the visible name of the second one is the same as the first one. That might lead to, for instance, impersonation (this being considered a security bug).

What version of the product are you using? On what operating system?

SVN r450

Please provide any additional information below.

I'm not really sure what are the characters we intend to support in usernames - what I'm sure is that we shouldn't let non-visible characters in. I am quite tempted in accepting only "string.ascii_letters" characters, since this is the "standard practice" in talkers. I'm not opposed to accepting digits or other chars, tho: people are used to be "r0n" instead of "Ron", or "the-greatest", or "the_greatest" instead of "TheGreatest"... But a decision about what to accept or what not to accept should be taken by tzmud's developer. What I might do in the meantime is to submit a patch anyway: I would wait if I didn't see this as a security bug, but as it is... ```

Reported by mindboosternoori on 2011-11-11 19:35:13
Comments (5)

Former user Account Deleted

``` How about when the person registers the name:

error = False for c in name: if c.isspace(): error = True

if error: ...

```

Reported by `missive@hotmail.com` on 2011-11-11 19:42:19
    2011-11-11
Former user Account Deleted

``` Trivial fix: https://github.com/marado/tzmud/commit/48feb5e8ac8ab5728f7a5e3baa4aa9ab90a1bdb9 ```

Reported by `mindboosternoori` on 2011-11-11 19:56:53
    2011-11-11
Former user Account Deleted

``` isspace would be insuficient: for instance \0 and other nonprintable characters aren't caught with isspace and would present the problem here...

You can, of course, also filter(lambda x: x in string.printable, name), but I'm not sure that even with both of those you would avoid all sorts of trouble... It's your call, really, but I would be more confortable with an "opt-in" solution, where we define which chars to allow, instead of which chars not to...

```

Reported by `mindboosternoori` on 2011-11-11 20:15:06
    2011-11-11
Former user Account Deleted

``` How about set(string.printable) - set(string.whitespace) ?

Allows people to get plenty creating with their login name, but is a limited set which can be further restricted if problems come up.

```

Reported by `missive@hotmail.com` on 2011-11-11 20:46:50
    2011-11-11
Former user Account Deleted

``` It's feasible, yes, I could write that patch if you want... But I would prefer if you first took a look into issue #50, since If we let users have any kind of printable characters in their name I don't know how could I implement that one...

To summarize, in that issue I want to add the chance to let users personalize their name with colors: for instance red(M)blue(arcos) (for "Marcos" with the first character in red and the rest in blue). I've seen that implemented differently in different MUDs: for instance: FRMFBarcos ("FR" meaning "foreground color red") or ^rM^barcos (^r meaning "color red"), but I thought after looking to TZMud's code that we could even do it using the "red(M)blue(arcos)" nomenclature. How do we achieve this I don't really care: just decide one way and I'm OK with it, but if users can have ^, , ( and ) characters in their names, then I don't know how to parse it anymore... well, not without adding (unnecessary, in my point of view) complexity.

Anyway, think about it. If you still want to let every non-space printable character in the name, I'll find a way to implement the colors in the name thing anyway... ```

Reported by `mindboosternoori` on 2011-11-12 02:34:45
    2011-11-11