In Part 4 we looked at more advanced methods of securing each page based upon the permissions for the logged in user. This final part discusses some additional ideas of how the application could be further enhanced...

User History
A typical example of a site that could make good use of the logins that I have just demonstrated is an E-Business site. Using the CustomerID field in a table called Sales you could determine what category of items the user buys most frequently and customize their starting page accordingly – banners; links etc. Even the layout and style of the web page could be dictated by the user. This is made even easier by the use of style-sheets using the <LINK> tag to include CSS files into an HTML document, so you could very easily change which CSS document is included in the file which could totally change the interface.

Another important security aspect to user history is the recording of actions by specific users. Using the Status and ID session variables it would be easy for admin users to track when records were deleted, added, and updated and who they belonged to using a table named Changes. Every action, such as adding a sale, would result in two records – the actual record in the sales table and a record in the changes table documenting the time and date of the change, and who did it, using the status and user ID. This could prove useful for larger sites with many users where administration has potential to become a nightmare.

Maximum Flexibility Permissions
Simply having user groups that allow or disallow access to particular pages, and use the ID to determine the contents of a page, there is a way to make an NTFS-like system where each file has it's own permission policies and can be set an a user-by-user basis. This can be achieved using a "permissions table" with two major columns – SalesPersonID and Filename, the filename being the name of the file that they are allowed to access. If an entry for a specific ID for a specific file does not appear in the table then they are not allowed to access it. This table could obviously be administered by admin users to give rights to specific users to specific files. The beauty of this is that the code on top of each page does not differ. It checks the session variable id against the Security table and checks to see if there is a match for the current file. If not, then you can be redirected either to an error page, or to the login page. Here is the code used:

<% Dim objConn, objRS Set objConn = Server.CreateObject("ADODB.Connection") objConn.Open "DSN=LoginTest;" Set objRS = objConn.Execute("SELECT * FROM Security WHERE ID = " & _ Session.Contents("id") & " AND Filename = '" & _ Request.ServerVariables("SCRIPT_NAME") & "'") If objRS.EOF Then Response.Redirect "error.asp" End If objRS.Close Set objRS = Nothing objConn.Close Set objConn = Nothing %>

That code can simply be copied and pasted into each secure file. You do not even need to change the filename for each page, as it is stored in the HTTP HEADER variable SCRIPT_NAME (ala Request.ServerVariables("SCRIPT_NAME")). Obviously there can be more than one record with a specific user ID, so that is not an issue.

Conclusion
I have taken you through from simple logins to creating your own mini file systems and by now you should be fully equipped to go out and make your own login and permissions.

Happy Programming!

Attachments: