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.
|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.|
A very simple HTML page including authentication tags.
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.
This example page shows how to redirect to another page (noaccess.html) if authentication fails.
Pattern page that posts to itself to create, modify, delete or view users, their community and OU associations, and their passwords.
|11 initialisesite.rhtm||A run once application that initialises the application by configuring the OUs and Communities that users can be put in.|
|6 rbexaccessuser.inc||Sets up default user and admin user if required.||12 noaccess.html||If authentication fails this is the page redirected to.|
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: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
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: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
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.