being so relaxed regarding usernames causes bugs

[GoogleCodeExporter]

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

Original issue reported on code.google.com by mindboos...@gmail.com on 11 Nov 2011 at 7:35

[GoogleCodeExporter]

How about when the person registers the name:

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

if error:
  ...

Original comment by miss...@hotmail.com on 11 Nov 2011 at 7:42

[GoogleCodeExporter]

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

Original comment by mindboos...@gmail.com on 11 Nov 2011 at 7:56

[GoogleCodeExporter]

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

Original comment by mindboos...@gmail.com on 11 Nov 2011 at 8:15

[GoogleCodeExporter]

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.

Original comment by miss...@hotmail.com on 11 Nov 2011 at 8:46

[GoogleCodeExporter]

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: ~FRM~FBarcos ("~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...

Original comment by mindboos...@gmail.com on 12 Nov 2011 at 2:34