strict validations for username?

[tmfelwu]

A user can signup with username "mean mean & mean" , shouldnt there be strict rules for username?

[ilanbiala]

Suggestions?

[tmfelwu]

1. start with alphabet
2. no spaces
3. alphanumeric, _ and .
4. limit length 3-100

[ilanbiala]

Is there any reason to limit it to that? What sorts of issues may we run into without these restrictions?

[mleanos]

From my perspective, I really wouldn't care what my User's use as a username. Just as long as my application can store it, and retrieve it.

Some of the apps that I've created, I actually forced my User's to use their email address as their username. This was more of a business rules consideration, and for ease of registration.

If you're not restricting to email addresses, then I say it's fair game as to what they can use as their username. Obviously, in a production environment you may want to prohibit offensive language/words. However, that's a whole other topic.

[tmfelwu]

@mleanos i am using username to generate profile urls for users xyz.com/username for that I had to restrict username in my app.

[lirantal]

@sparshy why not use an id for referencing the username instead of the plain username field from the database?

[codydaig]

You could also just Slugify the username for the url.

[tmfelwu]

@lirantal that wont be user friendly ,no user will remember his id
@codydaig a user expects his profile to open when he types xyz.com/username not the slugified version. look at any website twitter, fb, github all have strict rules for username.

also login feels bit weird with username with spaces. username : "mean mean"

[lirantal]

@sparshy if you're aiming for a website like about.me or twitter that really has your homepage and profile page use the username then I definitely agree, otherwise it doesn't make much sense. I don't remember my fb username nor do I use it ever.

I could argue that you could just move the /username part to be part of your logic and let users generate this based on nickname availability rather than force the username for this.

I still think that forcing a strict username schema in meanjs at this point (without showing any real value for it) doesn't make sense. If it were up to me I'd want to completely remove the username field and just use emails to login.

[lirantal]

Since no traction on this thread I'll close it up.
@sparshy you're welcome to update us with your progress on this one.

[hyperreality]

I'd like to chime in here and say that I was caught out by the default behaviour of the username field.

I have become accustomed to usernames not containing spaces nor symbol characters because that is the default on 99% of websites out there. My assumption was reinforced by the fact that my usernames were automatically converted to lowercase per #866 .

I built a route using a :username parameter and it was only a week later when testing my project that I realised it was possible to enter absolutely anything, including spaces, symbols, even Chinese characters into the username field and this broke stuff.

I can understand why you want to keep options open regarding the username field and allow people to add restrictions only if necessary. But in my case I was tripped up because the username field did not behave how I expected it to - normally you are allowed to type anything you like into the first and last name fields, but certainly not into the username field! Perhaps we should just add a warning to the documentation, or even remove the username field altogether according to @lirantal 's suggestion so people implement it properly themselves

[lirantal]

In retrospective I agree with restricting the username so either:

1. we restrict the username field per @sparshy's advices or others
2. remove it altogether

I think (1) is safer considering that other users may have used the username field in their project before and would want to maintain the same functionality.

So I'm generally open for new PRs on this topic.

[hyperreality]

BTW if anyone finds this it should be simple to implement, looking something like this:

Add this to the signup username form (along with a relevant ng-message):
ng-pattern="/^[a-zA-Z0-9_]*$/"

And on the mongoose model add a custom validator:

var validateUsername = function (username) {
  return validator.matches(username, /^[a-z0-9_]*$/);
};

[mleanos]

@meanjs/contributors Should we try to get this in for 0.5.0?

[lirantal]

it could be breaking some apps but I think we've done quite a bit of "breaking" anyway in 0.5.0 already so I'm not opposed.

[simison]

+1 for strict usernames. Logins will work with email+username in 0.5.0 anyway and it's fairly easy to remove username functionality, but since it's there, it should follow common patterns.

Here's what we're using:

/**
 * A Validation function for username
 * - at least 3 characters
 * - only a-z0-9_-.
 * - contain at least one alphanumeric character
 * - not in list of illegal usernames
 * - no consecutive dots: "." ok, ".." nope
 * - not begin or end with "."
 */

var validateUsername = function(username) {
  var usernameRegex = /^(?=.*[0-9a-z])[0-9a-z.\-_]{3,34}$/,
      dotsRegex = /^[^.](?!.*(\.)\1).*[^.]$/;
  return (
    this.provider !== 'local' ||
    (username && usernameRegex.test(username) && config.illegalStrings.indexOf(username) < 0) &&
    dotsRegex.test(username)
  );
};

• + regex has max length 34.
• Mongoose Model
• Tests

[mleanos]

@simison Those restrictions look fine to me. What are examples of illegal strings?

If agreed upon, we can get this in real quick for 0.5.0.

@codydaig @ilanbiala

[simison]

What are examples of illegal strings?

https://github.com/Trustroots/trustroots/blob/master/config/env/default.js#L30-L34

[mleanos]

Thanks. I guess I could have tracked that down myself :)

[lirantal]

Ok with me @mleanos, @simison if you wish to cook a PR for this, tests, etc.

[simison]

I'm gonna be on holiday coming week but feel free to copy stuff from @Trustroots

[sujeethk]

@mleanos per your request added a PR for this. Used the same code from trustroots(suggested by @simison ) as it is robust and included tests :)

I removed a few illegal strings like user, adminthat were on trustroots config since it will obviously fail existing tests. I could have renamed all tests using those usernames but it would pollute the commit with unwanted diff, let me know if you still want them renamed.

[mleanos]

@sujeethk The real issue with the "user" & "admin" usernames is due to our MONGO_SEED feature. We could re-introduce "user" & "admin" in the blacklist of usernames, and just rename the seeded usernames to something more descriptive like "seeded-mean-user" & "seeded-mean-admin", or something of the like.

After a brief overview, it looks like we're using "username" in our unit tests. We should be ok keeping them, since our blacklist doesn't include it. However, if we do want to add "username" to the blacklist then we'd be forced to update our unit tests. I don't see a need to do that at this point. We can probably re-address that at a later time if others feel the need.

[sujeethk]

I agree. I'll be adding those user and admin keywords, fixing the tests and adding client validation to the PR tomorrow