Surprising amount of freedom with player names

[dbenoy]

There are loads of characters that are allowed with player names. Really silly names like [#*% are perfectly allowed, for example. And concerningly, you can make names like: > or [SYSTEM]

And then stand in a popular room and do something like:

pose Due to a recent security breach, all passwords are being reset.
pose To preserve access to your account, please go to: https://furrrymuck.com

(and type your password into our password-harvesting phishing server)

It feels like it goes against the conventions of the internet in the modern era to allow usernames with such exotic symbols in them.

I think it would be more sensible to permit only alphanumeric characters, dashes, and underscores. I think it may be a good idea to just add in this restriction to ok_player_name() in db.c. If I understand the code correctly, this will prevent new players from being created with weird symbols, but won't affect the players that already exist, or the ability of commands to interact with them.

I don't even think there would need to be a @tune to continue allowing the weird symbols. It feels like so long as it doesn't break any existing users, no MUCK administrator would be mad about this restriction.

[tanabi]

99% of MUCKs I would say have wizards that create users rather than free registration, so I think honestly this is best left as a human-based filtration rather than imposing restrictions. I've been on MUCKs (such as SciFi MUCKs, etc.) where names with weirdnesses make sense. I'm inclined to leave it alone.

That being said, my preference would be to make an @ tune-able regex expression that will be used against player create so individual MUCKs can pick their own rules. These rules will be imposed in addition to existing rules (for instance I don't think you can name a player "home" or "here" among other reserved words if I remember right, and can't have spaces in them). We can make the default just alphanum, underscores, and dashes.

That would allow maximum flexibility while addressing @dbenoy 's totally valid concerns.

[wyld-sw]

Was thinking regex as well. Will code in a @ tune for that soon, unless someone wants to beat me to it :)

[tanabi]

@wyld-sw I won't beat you, I'm on vacation for the next week-ish :D Though I will probably have some more documentation done, that's really great to do on the flights. mfuns2.c is almost done! Though that's neither here nor there on this issue. I'll stop typing now.

[dbenoy]

I like the regular expression idea! Although it would make tp_reserved_player_names feel awfully redundant afterward.

@tune disallowed_player_regex=[^a-zA-Z0-9_-]|^(Reserved_Name1|Reserved_Name2)$

(I probably didn't do that regex right but you get the idea :p)

[wyld-sw]

Hmm. Would it make sense to automatically convert the current reserved_player_names to this new regex on database load? Another idea is to just add a tune pcreate_allowed_characters for a set of those additional to [a-zA-Z0-9-_] - and continue to use reserved_player_names.

Not sure what the best approach is.

[dbenoy]

There are some characters that were never allowed in player names. Apparently brackets ( ) are one example.

We could say if tp_reserved_player_names is surrounded by brackets, then it is treated as a regular expression instead. The brackets would get ignored when resolving the regex (but I think the way regular expressions work, brackets around the outside would end up getting ignored anyway.)

And then there you go. There is no chance this would ever collide with something somebody was properly using it for, because brackets were never allowed in user names to begin with.

[tanabi]

I think requiring the parens for regex is going to lead to user error. Honestly I think reserved player names makes sense as it is ... not every admin is going to have strong regex fu so I would leave it alone. They really serve two different purposes. One is a sanity thing, the other may be to avoid allowing players to have certain inflamatory or thematic names (i.e. don't let someone take Starbuck as a name on a Battlestar Galactica MUCK or whatever)

[dbenoy]

That's fine. No harm in keeping both, and you just have to satisfy the conditions of both.

I'm not so sure about the thematic vs sanity distinction. I'd definitely put thematic things in the regex one, because unlike tp_reserved_player_names, a regex can do partial matches, like making sure Starbuck is nowhere inside the name.

I suppose you could go in the opposite direction and instead of removing one, add even more. One regex that they can't match, and one regex that they must match, and keep the existing list one, too.