I will attempt to show many different ways that WebCrossing can integrate into these existing login systems by showing the ins and outs of what we call the "Authentication Filter".
HTTP - Stateless and Ignorant
First of all, the HTTP web protocol is a "stateless" protocol, meaning that each request of a web page or resource is completed and usually the connection is closed leaving the server to wait for another request. A simple web page makes many TCP/IP requests in the course of displaying the various pieces of a web page such as external CSS files, images, Javascript files, etc.
Since the protocol is stateless, there is no way for the web server to know who is asking for new information across these pages. Therefore, something must happen on the client side (browser) which identifies the user back to the server so that "state" of the user can be maintained across these page requests.
The browser can help with this in many ways including:
- Cookies
- Additional URL information
- HTML Header information
- HTTP Environmental Variables
- Basic Authentication
WebCrossing can integrate with any of these methods so that the user credentials can be transmitted across each page so that the perception of a user being "logged in" can be maintained.
Authentication filters are the basis for most of these login integration systems and I will start with one of the easiest, written in WCTL. This auth filter will log in ANYONE as the sysop of the site. This is obviously not practical in production, but is an easy way to bypass the sysop password on a database if perhaps the password is lost, etc.
The code for this is as follows:
%% macro authenticateFilter %% %% userLookup( "sysop" ) %% %% endmacro %%
This is an obviously dangerous filter to put into place because anyone that comes to the site will be logged in as the sysop, but it serves to illustrate some points.
One of the values that are "returned" from a filter is the User ID of someone in the WebCrossing database. the "userLookup" function returns this value after finding them in the DB and then that value is "printed" to the output buffer, so the result of executing this function is to return the userID of the sysop. This then logs in the person specified by the userID.
The authentication filter is executed for EVERY SINGLE web request made to the server, so we try and make it as simple and as fast as possible.
There are LOTS more uses of authentication filters and different ways to write them, so I will continue this in future blogs on this subject.
Dave Jones
dave@lockersoft.com
http://www.youtube.com/lockersoft