Access Control: Browser Does the Work

run example

overview   applications   limitations   structure diagram   files   details


This is an example that illustrates the most simple way of access controlling a website by using the in-built browser name and password mechanisms. Each page to be secured has a Redbourne tag (<rb:authenticate>) enclosing the page content and thats it! When a user attempts to access the protected page the browser will prompt him to enter a username and password. If the username and password is valid for the group specified in the authenticate tag, access will be allowed. As a next step another example page shows how to redirect to another page if authentication fails.

A contacts management application lets you set up the names and passwords and the communities/OUs they are in.


This example application is applicable to all sites requiring access control. It is especially easy to add access control to an existing, static web site using this technique.


Due to the way browsers typically work the user cannot "logout" (browsers cache passwords so that the user is not prompted for every page, the cache is emptied when the browser is shut down).

The only way to login is via the browser dialog box. This means that there is no way to capture any other user information or elements of design with the login.

Users can only be manually entered via the management application screens. (Note that this can be overcome by mixing this straightforward application with some of the techniques from the other examples (for instance initial logon could be after a user has self-registered).

SSL needs to be used to ensure name and password are protected.

Structure Diagram

Application Application Administration



Management Application

1 index.rhtm Page that points to this file and provides an entry point to the normal and management applications. 7 index.rhtm Home page for the management application. This page is access controlled but entering a name and password is not mandatory.

2 access1.rhtm

A very simple HTML page including authentication tags.

8 userfrm.html
9 usertofrm.html

Application entry point forms that allow the inputting of search strings for users. The second form has a session time out message at the start.

3 access2.rhtm
4 noaccess.html

This example page shows how to redirect to another page (noaccess.html) if authentication fails.

10 useradmin.rhtm

Pattern page that posts to itself to create, modify, delete or view users, their community and OU associations, and their passwords.

5 access3.rhtm

This example page shows how to redirect to another page using Redbourne JavaScript rather than tags.

11 initialisesite.rhtm A run once application that initialises the application by configuring the OUs and Communities that users can be put in.
6 Sets up default user and admin user if required. 12 noaccess.html If authentication fails this is the page redirected to.

Detailed Explanation of Browser Password Operation

The way a browser handles usernames and passwords is not at all obvious! What happens is that a browser unknowingly requests a protected page which has the effect of forcing the web server to respond with a 401 error code - "authentication required". The browser then puts up a dialog box prompting the user to enter a username and password. After the user has entered the required information the browser re-requests the page this time supplying the user entered username and password.

However to save a user typing in the same details every time a protected page is requested a browser will cache the last name and password entered and automatically provide it each time it gets a 401 code. Thus in this example after a successful logon the user will be able to access both links without having to re-enter name and password each time. (So to prove the access control is working try logging on with a wrong name and password initially!). This happens until the user closes down and restarts their browser. The value for domain is what is displayed when the username and password are entered on the browser.

This system works simply until an application wants to take specific action when a user fails to supply the correct username and password, for example informing them that they need a specific access level to see the desired page. In this case a the specific page needs to be supplied along with the 401 code. Depending on the browser being used if the user presses "cancel" or supplies a rejected password more than a certain number of times the specific page content will then be displayed. A simple way to achieve this behaviour in the Redbourne system is shown in the access2.rhtm example page.

In access2.rhtm the authenticate tag looks like this:

<rb:authenticate domain="Redbourne example" community="user" mandatory="no" >

Setting mandatory to "no" means that the page will be executed by the Presentation Engine even if authentication fails. Because we can test if a user has entered an incorrect username and password we can implement a mechanism to "force" the browser to re-prompt the user, supplying a page to display if they press cancel or exceed the maximum number of retries the browser allows. If you look at the code there are four groups of Redbourne tags used. <rb:test expr="something" > togther with <rb:true> and <rb:false> enables whole sections of HTML to be conditionally executed by the presentation engine. The method returns "AuthOK" if access rights to the page have been automatically confirmed and this test is used to determine whether to put up the normal page contents or a special "no access" page.

The noaccess.html page is actually generated by redirecting to it with a <rb:redirect> tag. However we want to tell the browser to only show it if the user has failed to log in. This is achieved by forcing the web server to return a 401 error code along with the redirected page content. The <rb:return> and <rb:header> tags "force" the 401 error code and appropriate header information.

Two other things to note. The first is that access2.rhtm uses Redbourne XML tags to achieve its functionality, exactly the same results can be achieved by using Redbourne JavaScript (but <rb:authenticate> tags are still needed to protect the page) - access3.rhtm shows how to do this. The second is that although the page to be output is achieved via a redirect the 401 return code and headers are set in the originating page (i.e. the page that would be shown if access was allowed). This works because the redirect function is a structured redirect in that valid program flow continues in the originating page after a redirect tag or method. An alternative strategy would be to set the headers in noaccess.html instead; in this example the author thought that it might be more valuable to have a "clean" noaccess.html page enabling it to be used in several circumstances.