I have just finished a painful round of coding adding various options for how user registration should be done.
Traditionally (for example on most forums) when a new user wants to sign up, they are asked for a username, password, and email address. At that point a validation email is sent to the users registered email address that they must click to prove that it their email, after which they can log in.
The new optional mode asks the user ONLY for an email address, and then forces the user to provide the other required fields (username, password) only after they have visited the validation link; this can be used with bridged accounts as well, and by default (though it is an option) will create only lightweight validation table entries until the validation is complete, which avoids polluting the user table with unvalidated failed accounts.
There are several advantages to the new method:
- Simpler initial registration, less confusion for users and less mental barrier to signing up
- The part that most often goes wrong (providing wrong email address) is caught early before user wastes any time -- and they haven't ended up "reserving" a username that they never follow through on.
- The user table is only validated users -- cleaner and smaller
Drawbacks:
- The use of a specialized pending-validation table *might* make it more programatically painful to report and track bad behavior.. That is if we created a non-validated user account right away, we could have one and only one unified system for tracking users behavior, ips, access attempts, log, etc. Wheras if we postpone creating a user until validation, we need to provide investigatory tools both for the normal user table but also for the validation pre-registration table.
- If we only gather email address from user initially, we can't let them in right away, pending email validation, to access some limited areas, the way we could if we got their username and password initially.
- Any other drawbacks I'm not thinking of?
Note:
It's been particularly painful simultaneously supporting both this new method, as well as the traditional method of registration, as well as options for how to handle bridged logins in these cases, which introduces some hairy scenarios (like when you want to allow bridged users to not be forced to provide an email address, etc.)
Keeping the multiple options for user account registration may not be worth the extra complication in the long run, and I am thinking of dropping support for the traditional registration approach (get username,email,pass at initial signup). If anyone has strong feelings either way let me know.
In general I'd say the thing that's really kicking my ass lately with YUMPS is trying to support options for having so many different ways to do things..
Recent Posts
Actually now that you remind me, you could browse that list online here:
