New user passwords shouldn't have to be alphanumeric #272

brianewing opened this Issue Jan 17, 2012 · 10 comments


None yet
3 participants

I read the source after getting an error from the user creation form about my password being alphanumeric - and noticed that this isn't enforced when changing your password.

Is this in error or is there a reason it has to be alphanumeric on creation? Would be better if the extra step isn't required...


chrismatthieu commented Jan 17, 2012

Yes, I agree with you. Feel free to send us a pull request if you get a chance. Thanks!


contra commented Jan 18, 2012

Fixed! Only restriction now is no spaces to prevent future issues. Thanks for bringing it to our attention

contra closed this Jan 18, 2012

I use spaces in my passwords to make them easy to remember - it's a common thing. This is debilitating the API in case someone using the CLI doesn't know that arguments with spaces should be quoted - surely that's common knowledge amongst developers and sysadmins?

-1, IMO. This restriction seems superflous and doesn't fix my core issue - that I wanted to use spaces in my password, heh.


contra commented Jan 18, 2012

V2 doesn't have any limitations for passwords. Please wait until then unless you'd like to rewrite the V1 CLI and submit a pull request

Hmm? The V1 CLI shouldn't have any limitations on passwords. Your password works just fine if you escape it - it's common knowledge that args with spaces should be quoted!


contra commented Jan 18, 2012

I don't know what you want me to say - you have to wait for V2.

Workaround until V2 is ready:

nodester user setpass sendtoken
nodester user setpass <token> "your cool password with lots of                spaces"

Once your commit is deployed, I'll get "failure - invalid password. must be at least 1 character with no spaces".
We're on the same side here, why is there hostility?


contra commented Jan 18, 2012

It hasn't deployed yet - feel free to change your password before it does.

Spaces aren't alphanumeric. V2 will allow spaces in passwords, and V1 can equally support this now. When the commit is deployed, it still won't support spaces. My proposed fix does. You'll have the same CLI (arguably non-)issue in V2.

If a user properly quotes their password with spaces, they'll be told they can't use passwords with spaces in case they mightn't have quoted it. Yet if they don't quote it, they will not get that message. They'll get an error, or just the first word will be used, which is worse. The requirement doesn't even solve the vague problem it was put in place for.

I don't mean to be an ass, but I don't follow your logic.


contra commented Jan 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment