Account services

Authentication and login links

Eionet has in recent years moved on from a web of websites, where the main involvement for the average participant was with one website—CIRCA. With one main website requiring login, it was not important to ensure a consistent look and feel for authentication.

Today we have CDR, DD, ROD, Workplan and the topic centres have initiated some restricted areas on their websites.

We have centralized account names, and pushed its use. Now most Eionet websites use it. It is time we make specifications for a consistent user interface. We have looked at the available usability literature, evaluated the current mechanisms and made it fit within the constraints of the Eionet look and feel.

People won't use your web site if they can't find their way around it. Whether you call it usability, ease-of-use, or just good design, companies staking their fortunes and their futures on their websites are starting to recognize that it's a bottom-line issue.

—Don't Make Me Think, usability expert Steve Krug

Many of our websites are built with Zope, and even though some of us find it easy to append /manage to the URL to login, it is not something we can expect the occasional user to remember. In fact, to ask the user to remember information—Where to login? Am I already logged in?—is not going to work, and the design reflects this.

The specification:

  1. The login must be available on every single page. We have made it a standard link in the top right corner with a little icon next to it. The link is also used to show state; if the user is not logged in, it says “Login”. When the user is authenticated, it says “Logout (userid)”.

    What needs to be preserved? Whatever would have happened if the user had refreshed the page without logging in.

  2. After authentication the user is returned to the page where he clicked on the login link. This is so the user won't get disorientated and try to get back to the page he left. You can show different (more) information on the page after login, as long as the user still recognises it as the same page.

  3. After authentication the top right shows a logout link. This is because the user expects symmetry, and if the logout link isn't there he gets frustrated. If the website uses Basic-Auth, the only thing possible is to let the logout link go to a page that tells the use he must close the webbrowser to logout.

  4. There are essentially two authentication mechanisms for websites. Basic-Auth, which is part of the HTTP standard, and cookie-based. The cookie-based mechanism is a combination of a form the user fills out with his user name and password. Then a cookie is generated that the webbrowser sends in all future communication. We allow both mechanisms.

  5. You can use Javascript to avoid a costly roundtrip to the server, but it still has to work with Javascript turned off in the browser.

Restrictions on cookie-login

Cookie-based login should not use a popup to ask for the credentials. And why not, as this is how Basic-Auth works? No, it is how Basic-Auth works on graphical webbrowsers. On text-based, Braille and other alternative browsers, Basic-Auth works differently. Using a popup blocks the back-button from working and it is difficult to make the mechanism work without Javascript. The correct approach is the simple one. Just create a page with a simple form.

If the user goes directly from a bookmark in his browser to a restricted page, and he's not logged in already, the system must provide him the ability to authenticate immediately, and not send him a "Not found" or similar error code.

After authentication

When the user is logged in, it is appropriate to show him what new functions are available in the form of new buttons etc. You should avoid showing buttons that the user doesn't have access to after login. If the user has no extra rights after login, then treat him as having no extra rights than an anonymous user — don't deny his login attempt.