devsnd
User account manipulation via CLI + allow special characters for user names and passwords
Hello,
I'm trying to add registration option to CM. Related issue to this super cool feature was discussed: #401
From #401 thanks to @devsnd --adduser switch was born. Can it be extended with ability to change user password via command line, please? Unfortunately there is no such ability for now..
$ ./cherrymusic --adduser cmuser cmpass
[150507-00:54] added user: cmuser
$ ./cherrymusic --adduser cmuser CMpass
[150507-00:54] ERROR : cannot create user "cmuser", already exists!
Also, this can be universal switch with all features presenting in UI admin panel:
- allow / disallow download option for certain user
- limit / unlimit audio bitrate for bandwith saving #535
- edit / change username password
- add / delete user
etc
Thanks!
From #401:
Hello @systems-rebooter,
the last post to this issue was over a year ago. I recommend opening a new issue for your requests (and make a reference to this one). This way, it is a lot easier for us to handle things. Thanks!
usernames and passwords have to be made up of the letters a-z or numbers, otherwise they wont be accepted.
I'd like passwords not to be limited by a-z and numbers only and accept !@#$%^&*(){}[], to be stronger. How may this be accomplished? Also, as usernames I'm planning to use emails (which will help with password reset).. Can you avoid this limitation? Please, please, please....
Hi @systems-rebooter!
I agree that a more complete CLI interface would be nice. Deleting users and changing passwords should be supported.
And it's true that it does not make any sense to limit the character space of the passwords created on the command line. I don't know how that came to be ... :question:
Hey @systems-rebooter!
I have implemented the command line switches for deleting users and changing their passwords.
$ ./cherrymusic --deleteuser USERNAME
and
$ ./cherrymusic --changepassword USERNAME NEWPASSWORD
Also, I have lifted the limitations on the passwords that can be used on the command line. If you do use special characters, make sure to put the password in double quotes ", because some characters might end the command (e.g. &) and the password will be truncated from there.
Before setting the user options on the command line, we have to make sure that it's impossible to set any values that could break CM, so if you really need that feature, open another issue and we can discuss it there further :smile_cat:
Whoho... Super-great news! Thanks for everything you did @devsnd !
Especially for hardening the passwords and --changepassword feature (i really missed reset password in auto-registration).
Nerd question - if password contains " symbol - how to mask it properly? Will \" be enough?
ThankUThankUThankU :tada: :walking: :tada:
P.S. Am I right to assume that 0.36 will born pretty soon, 'cause every single issue has been fixed / responded :ghost:
Nerd question - if password contains " symbol - how to mask it properly? Will " be enough?
That depends on the shell you are using. In Bash for example, that should work. But you can't escape all characters with \ within double quotes. You can expand the allowed characters by putting the password in single quotes. See this for more details.
Generally, I wouldn't recommend using too exotic characters in passwords, especially if they interfere with your shell syntax. This also might get tricky if you find yourself sitting infront of a foreign keyboard and have to find out which key combination generates a "µ" or something.
Thanks for the info @6arms1leg
I know the issue already closed, but can we not limit USERNAMEs as well.. So emails can be used?..
develop]$ ./cherrymusic --adduser "[email protected]" cherrypass
[150523-11:48] ERROR : usernames may only contain letters and digits
I constantly requesting this feature again and again, because was able to add registration to cherrymusic (it was loooong way of trials and errors before making it working, since I'm not a programmer)
It's nice to let people log in with email address as people are more likely to remember email addresses than usernames, especially if they haven't been to the site in a while. Also password resetting will be in place without using additional database logic..
Make me happy... Please @devsnd :ghost:
I know the issue already closed, but can we not limit USERNAMEs as well.. So emails can be used?.
Hmm... actually, I'm not in favour of that idea. Allowing e-mail addresses as user names suggests that CherryMusic offers some kind of e-mail service (e.g. e-mail notifications/newsletter/password reset) for its users – which it doesn't. This might cause some confusion. As long as CherryMusic doesn't feature any e-mail service, I'd rather not allow e-mail addresses as user names. Additionally, if e-mail addresses were used, they should be validated (for correct form) and verified (to see if they exist).
@devsnd, @tilboerner, what do you think?
Well, I don't consider email addresses to be such a special case: the question is rather, which special characters should be allowed as a username. In my opinion an @ sign would not be to bad, but what othe characters should we allow then as well? Also: is lol the same username as loł? Should we enforce the usernames to be saved normalised for this scenario?
My reasoning about email addresses: I don't like it, but would (grudgingly) be ok with allowing @ characters in usernames.
- Pro: Email addresses work nicely as identifiers. (Extra-nicely, because people already know them and likely had a hand in choosing them.)
- Contra: (@6arms1leg's point) They're problematic identifiers unless verified. Otherwise, they're really just names that look like email addresses, inviting confusion with the real thing. Also, people could register with somebody else's address, basically posing as the real owner while also locking them out. The need for verification can create additional problems when the email address is the primary account identifier and people want to change it.
- Failed compromise: Let admins decide and make allowed symbols configurable (to an extent). Creates overhead and leads to problems when the configuration is changed down the road, unless the code is careful with its assumptions about existing usernames.
-
Conclusion: I'd argue the problems under 2 don't apply to CherryMusic, which is explicitly not meant for large or unknown sets of registered users. While this also reduces the practical need to employ email addresses as usernames, and while I don't exactly like the idea for CherryMusic, I think we could still allow the
@. However, @systems-rebooter, CherryMusic will never even try to send email to people's usernames. - Bonus: I don't think CherryMusic users need to have their email addresses saved at this point; but if they did, I'd do it in addition to usernames and let people log in using either.
@devsnd:
what other characters should we allow then as well?
Personally, I'd like to disallow at least the following:
-
URL reserved characters, possibly excluding
@; -
<and>; - quotes and backticks;
- whitespace;
- unprintable and control characters.
Allowed should be:
- unicode letters and digits,
-
._-.
Also: is lol the same username as loł?
No, they're different letters. Let's not screw around with how people like to spell their names. :)
Should we enforce the usernames to be saved normalised for this scenario?
Yes, they should in fact be normalized as soon as feasible after input. Here's a great resource about unicode equivalence. NFKD and NFKC look particularly interesting, especially when it comes to ligatures and other visual styles, which I'd say don't change the spelling of a name.
