-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature suggestion: registering with password and email at the same time #427
Comments
Nope, if they put the wrong e email they are locked out of the account. |
Not for password / email combination that sNuuFix describes. But for what he describes it would seem like an option offering to either |
@ljacqu What do you mean? |
Yes, I forgot to mention that it should be optional, so users who don't want to give out their email because they don't trust the server yet are not forced to write it. But I don't know what message would be the best to show that it's optional. also there may be problem with users who are used to write password twice on other servers, so there must be some error checking for email parameter. I don't know really what would be the best, it's up to you guys to decide if it's worth the trouble. This is just a suggestion from usability standpoint. |
@ljacqu Already merged, please close the issue. |
@koca2000 I still need to add some logic for making the email optional. |
@ljacqu I am not sure if I want to give them choice. What about secondary register option in config? |
@koca2000 Thanks for the reply, we could add another mode where the email is or is not mandatory. From a usability perspective I wouldn't suggest to make the email mandatory. |
@ljacqu I suggest to add secondary-type node to registration config (which could be NONE) in which can server owner add alternative to primary registration type (e.g. /register pass or /register pass email; /register email or /register pass email; etc). |
+1, thanks for your input. I'll have this done on the 31st at the latest. Sorry for the delay. |
Hi @koca2000 , may I ask you to verify again? The config can look something like this now: registration:
# [...]
# Type of registration: PASSWORD or EMAIL
# Password = account is registered with a password supplied by the user;
# Email = password is generated and sent to the email provided by the user.
type: 'PASSWORD'
# Second argument the /register command should take: NONE = no 2nd argument
# CONFIRMATION = must repeat first argument (pass or email)
# EMAIL_OPTIONAL = for password register: 2nd argument can be empty or have email address
# EMAIL_MANDATORY = for password register: 2nd argument MUST be an email address
secondArg: 'EMAIL_MANDATORY' If your config.yml already has the registration.type setting you need to update your config.yml manually. Configurations with the old settings before |
@ljacqu That looks pretty good for me. |
Fine, thank you ;) |
It would be nice to have the option to ask player to register password and email at the same time.
For example with command "/register password email" because then confirming password could be removed, as the password is already seen on screen and there would be an option to reset it with email (ofcourse if the email isn't fake, that can be avoided in most cases by doing quick dns lookup on the existance of MX records on email domain part). This is the recommended signup strategy by todays modern usability standarts (http://uxmovement.com/forms/why-the-confirm-password-field-must-die/) and would enable a possibility to send welcome email to new players with instructions and tutorials what to do next. This sending option isn't even needed in plugin, because anybody can check the database for new entries and send emails with cron or use insert triggers. Confirming email is not nescessary as it would frustrate users who just want to start playing and the user is responsible himself for it's validity if he ever want to reset password.
At this point we are offering an option to add email at first login in website + the AuthMe's ingame option to add email, but both of these are rarely used.
The text was updated successfully, but these errors were encountered: