overview applications limitations structure diagram files details
This is an example that illustrates the way to do access verification entirely under the control of the server JavaScript. In this example browser authentication is not used, instead session data is used to indicate a "logged in" state. A facility to logout is also provided; a logout will occur automatically when session data expires after 30 minutes.
The contacts management application in example one lets you set up the names, passwords and communities/OUs if required for this example.
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.
As this example uses session data a user needs to have cookies enabled or session markers have to be appended to all forms and URLs that are accessed in the logged-in state. The example uses session markers.
As session data is used to hold "logged in" information you must be aware and ensure name clashes do not occur.
Conversion of an existing site takes more effort (particularly if you want to insert session markers).
SSL needs to be used to ensure name and password are protected
| Application |
|---|
|
|
|
Application |
|
|---|---|
| 1 index.rhtm | HTML page that points to login/logout pages, as public/member pages. |
|
This pattern page lets the user enter a username and password, setting a Session variable if successfully authenticated against the contacts template. |
|
|
These pattern pages are included by several of the pattern pages here, and provide an easy means to store data in the Session, and also to check a user has been logged in successfully (using Session variable for confirmation) If not logged in, checklogin.inc redirects to login.rhtm. Prefs.inc contains some global constants (communityName) |
|
|
This is the page that gets called if the user selects the logout button on the access pages. It clears the session logged-in status and informs the user. |
|
| 7 privatefile.rhtm | Example of a protected pattern page. |
|
Non-protected page. |
|
|
This include file is used by the example to initialise a default user named guest. |
|
Programmatic authentication is achieved by having a members' entrance/login page where a user enters their username and password. This combination is then authenticated against the contacts template, and if successful a Session variable is set to a certain value (in this case the Session variable is named 'loggedIn' and is set to 'true' if the authentication is successful.
A pattern page, checklogin.inc is included by all pages that require authentication and these pages then check if the Session variable 'loggedIn' is set to true/false. checklogin.inc sets a global variable 'loggedIn' equal to the value of the Session variable, making it easier for protected pages to be implemented.
