Designing user logins - part one: account creation and sessions

The "login" box on a site may look like the simplest of forms, but the backend to it needs careful design in order to give adequate flexibility. Perhaps the most useful tool for this design, is "use cases", basically short descriptions of operations that need to be performed with the system.

Here's a few:

1) Login/session creation:
- The user must be presented with a login box requesting username and password, either directly on the front page or via a suitable link.
- The system must accept and validate the login, and either return an appropriate error on invalid details or system failure, or initiate a session within the site.
- Binding sessions to IP numbers is impractical for a wide range of reasons, so a session token must be presented to the user's browser, and passed back by that browser to the website whenever a page is requested.
- The user must be able to log out at any time, and invalidate that session token at both client and server side.
- Optionally, you may wish to automatically log out any sessions that are inactive for a given period of time.

There are two key ways that can be used to pass this token - either by embedding it in all links in pages served to the user, or by means of cookies. My own preference is for use of cookies, as it keeps all URLs within the site clean for bookmarking, and does not require a custom rebuild of every aspect of every page (although PHP can actually handle this last for you). The use of cookies, however, requires that your site make its cookie policy available to users before setting any.

2) Account creation:
Unless there is a very specific reason that you don't want to have any idea of the identity of your users, it's often worth binding the account to an email address. To do this, you'll need to send a link or validation token to that address, and provide a mechanism to check this token before making the account 'live'. I advise that you make this validation page seperate to the login page, as confusion invariably arises otherwise.

You may also wish to control who can make an account on the site, either by controlling who has access to the account creation page, or by validating any submissions made on that page yourself prior to sending the validation token email to the user.

Use case:
- User visits the "create account" page, submitting an email address, user name, and password (entered twice to verify).
- Optionally, user must also enter an "account creation" token which they have been sent seperately.
- The username is checked, to make sure that it is unique within the system (usernames should ideally not be case-sensitive), that it meets requirements (eg, over 6 characters) and optionally that it does not misrepresent itself (you may prefer to block names containing 'admin', 'root', 'maintainer' and so on).
- The two instances of the password must be checked to match, and meet any constraints that you think appropriate (must be over 6 characters, must have at least one number and one letter, etc).
- The domain part of the email address can also be checked, to see if a delivery attempt will be possible, by confirming that there is either a DNS A or MX record for it.
- If the above conditions are not met, inform the user and allow them to correct the appropriate details (don't make the user re-enter correct details though).
- Once the conditions are met, store them in the site database and either: send the validation/introduction email, containing the validation URL and token, to the user, or: put the account in a queue to be validated by the site admin, sending the email after this validation has occurred.
- When the user visits the validation URL, submitting the token, check it (and the account name) against the database, and set the "active" bit on the account if the details are valid. You can then allow them to log in.

Of course, once you've allowed a user to log in to the site, you need further logic to decide what they can do with that login, and it's usually worth providing options to change email addresses and passwords and recover (or reset) lost passwords. More on this in a later post.
Posted by parsingphase, 2004-04-11 09:55

Anonymous user



Contact Richard