Logins and Permissions, Part 5By Peter McMahon
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...
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
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
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 –
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:
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
Request.ServerVariables("SCRIPT_NAME")). Obviously there can be more than one record with a specific user
ID, so that is not an issue.
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.