Email address validation afterwards

trustmaster commented 13 years ago

Current user registration procedure forces a user to validate his email address before being able to login (unless validation is disabled).

Modern usability best practices handle email validation slightly different. Instead of validating up front, they validate afterwards. The new user is able to login immediately (or even better: he's automatically logged in after registration). A validation email is still sent, but the user has a period of 24 hours (configurable) to validate the address, before his account is deactivated.

The best way to implement this is through a plugin that disables a user account if the email address wasn't validated within a set period of time. Regular email validation should be disabled to avoid conflicts.

trustmaster commented 13 years ago

How about spam bot registrations? Originally e-mail validation was against spammer registrations.

esclkm commented 13 years ago

add auto login after registration

trustmaster commented 13 years ago

What about spam bots?

ghengeveld commented 12 years ago

Use captcha if you worry about spam bots. Personally I prefer to not care about bots until you actually have troubles with them. There is no need to fix something that's not a problem. Active site management is a better way to handle it anyway. Usability should be higher priority.

jasperjorna commented 10 years ago

Maybe we could provide this functionality out of the box instead of with a seperate plugin.

Instead of the current default behaviour, the registration process logs the user in immediately and sends a confirmation email to the user's email address. If the user does not confirm his account within a specified time span it will be disabled until further action and if so desired removed after some time. For sites that are affected a lot by spambots, we could limit the new user's abililty to post until the account is confirmed. CAPTCHA could always be added if necessary but shouldn't be in place by default as it's bad for user experience.

The registration process should be as easy and user friendly as possible with a minimal amount of steps.

macik commented 10 years ago

I'm already wrote somewhre about login process that combines best UX practices… but repeat it here.

Modern UX supopse that «easy way is best way». So…

Registration process:

For resistration user asked only for : e-mail
On this e-mail user gets «welcome» message with: strong temporary password, note for password change and direct link for profile page (with ability to change password),
Get PM (can be delayes 1 day or so) with note to change temporary password
[optional] User instant and automatically authorized in CMS
[optional] Temporary password can be done expired (after 1 day or so). If password expire user can start standard password recovery procedure.
[optional] After automated authorization user can not use site before setup actual password

Comments:

For 1. This can be one input field — email (login would be the same as email, and can be changed later) or 2 fields (login + email)

Validation process (to get common user rights):

In case auto athorization is «On»: first authorization with temporary password (from welcome email)
In case auto athorization is «Off»: changing temporary passwod for new one

Password recovery process

Standard — with e-mail link to set up new password

Overall benefits:

One input field registration
Auto athorization (if enabled)
Intuitive (latent) user validation

In russian:

[тема возникала и раньше, так что могу где-то повториться…]

Мне импонирует следующий подход (агрегирующий многие UX практики)…

Регистрация

— для регистрации запрашивается только e-mail (или ник+емейл), на который высылается «условно-временный» «условно-сложный» пароль — в этом же письме напоминание и прямая ссылка на профиль или иную страницу на которой можно сменить пароль — если в системе есть внутренняя почта или уведомления — туда продублировать напоминание о необходимости сменить пароль (можно с задержкой в 1 день). — [опционально] сразу авторизовать пользователя в системе под зарегистрированным именем (емейлом), (можно с ограниченными правами, пока не подтвердит свой емейл. — [опционально] доступ по временному паролю можно ограничить например 1 днем (далее, если не сменил — процедура восстановления пароля). — [опционально] после входа по временному паролю не пускать далее пока не сменит временный пароль

Процедура валидации емейла (и получения статуса полноценно зарегистрированного) разниться в зависимости от реализации: — если пользователя не пускать сразу в систему, то валидацией будет первый вход по временному паролю — если пользователя пускать в систему сразу, то валидацией будет смена временного пароля на «постоянный»

Процедура восстановления пароля стандартная — письмом ссылка на страницу где можно установить новый пароль.

Плюсы здесь следующие: — пользователь заполняет 1 поле — пользователь сразу после ввода емейла попадает в систему (в зависимости от реализации) — интуитивная (скрытая) валидация емейла (см. выше)

Минусы: — (в зависимости от реализации) пользователь не может войти в систему не имея доступа к почтовому ящику. Но это условное ограничение, т.к. он все равно, как правило, ничего не может сделать в системе без подтверждения е-мейла кликом по «ссылке из письма».

Если вы видите другие плюсы и минусы — комментируйте.

jasperjorna commented 10 years ago

For resistration user asked only for : e-mail On this e-mail user gets «welcome» message with: strong temporary password, note for password change and direct link for profile page (with ability to change password), Get PM (can be delayes 1 day or so) with note to change temporary password

I think 3 mandatory fields is the best experience for the user. Obviously only asking for just an email address allows new users to quickly work through the initial step of the registration process, but the downside of this is that it requires more work afterwards for the users to complete their basic profile setup.

If we require 3 fields; username, email address and password, their profile is pretty much ready to go when they hit the submit button. We can sign them in and directly forward them to their profile page. Depending on the site's configuration we can display a message on their profile informing them that a confirmation email has been dispatched and that some restrictions might be in a place until they confirm their account.

macik commented 10 years ago

it requires more work afterwards for the users to complete their basic profile setup

it depends on type of project and in one thhird part of my projects it not sensitive is user had their actual nickname or e-mail used for it. Any way its only my point of view.

Nevertheless, My hopes in rewriting (updating) user module is to make it more customizable — i.e. separate it to single functions that can be used as complete API for user managemant process (add/delete/rename users, send validation email, check password, change password, change user group, authorize user, etc.)

Now I don't want to write own reg/login scenario for security reasons. I want to rely on official proven API for it.

Cotonti / Cotonti