The last hurdle in between me and being able to code an actual module for use in InkLog is an authentication mechanism. I’m so excited to actually get InkLog working on revjim.net that I’m tempted to skip this step and just hard code a username and password into a generic authentication module for the time being (since my personal authentication needs are fairly simple: I can do everything, and you can only read or enter comments). However, coding it this way will leave way too much room for other people to shoot themselves in the foot and doesn’t provide the flexibility that the rest of InkLog screams about. InkLog needs authentication, so that’s what’s next.
I’ve been looking around for an existing authentication package that I could use (much like I stole Smarty templates). Unfortunately, I can’t seem to find something that is application independent with a flexible API.
There are several authentication methods that I could implement, and I’m really not sure which is best. Some are more flexible than others. Some are more simplistic than others. Some require less overhead than the rest.
View based Authentication
Clearly, the method with the least amount of overhead, the simpliest method of management, and the the least amount of flexibility is a view based authentication module. With such a method, a model would be created with the following methods: isLoggedIn(), logIn($username, $password), logOut(), addUser($username, $password), deleteUser($username), hasPermission($username, $perm), grantPermission($username, $perm), and revokePermission($username, $perm). isLoggedIn() and hasPermission() would be exported to the view (aka, Smarty), and the rest would be made available to the controller.
It would be assumed that every user, by default, had access to every page. In a particular view, one could call {hasPermission type='addWeblogEntry'}. If a user was logged in and that permission was assigned to that user, the user would be permitted to continue. Otherwise, an error would be displayed and execution would cease. This means that the overhead of checking permissions only occurs on protected views, which, for the most part, are only those views involved in the management of the site. However, this means that, restricting read access to certain portions of a site would be possible, but difficult and error prone.
Model based authentication
Another method is to use something similar to unix file permissions on the nodes table. Every user could be assigned read and/or write permission on a particular node. Everytime a list of nodes was created, the username of the logged in web user would have to be considered to ensure that access to the nodes being listed was granted. Additionally, create and/or delete permissions could be placed on any particular path and would be specific to the item type. This means that I could allow any user to create a “comment” in “/weblog” but, only allow user “revjim” to create a “weblogentry” in “/weblog”. Each individual node and path could be proected in an unllimited number of ways.
The issue with this is that, determining which items to list for a user becomes difficult. If a user asks for an RSS feed of the entire site, each node will have to be examined to determine if the user has read access to that node. This involves checking the users permissions, and the permissions of all the groups the user belongs to. A generic groups “EVERYBODY” and “LOGGEDIN” could be used to make this sort of lookup a bit faster, but the complexity of this query increases dramatically with this type of permissions system. Additionally, the node model would no longer be independent of a permissions system, as permissions would have to be analyzed within it. This means, essentially, that the node model would simply need to be modified to support such things. However, this method does seem to be the safest and most featureful. It also means that additional interfaces (XML-RPC, Email, NNTP, other Views, etc) wouldn’t have to worry about determining and/or verifying permissions.
This system would require a separate database table to store permissions. Each node could have the following permissions: READ, WRITE. Each path could have the following permissions: CREATE, DELETE. Each permission could be assigned to an individual user, a group, or a system-group (ie, EVERYBODY, or LOGGEDIN). Before any node method was called, a username and password would have to be supplied (or it would assume anonymous).
The View based method is easy and light-weight yet provides lots of ammunition with which to shoot yourself in the foot. The Model based method is complete, very functional, yet heavier on the server side. One again, the same issues arise: do I choose speed or flexibility?
I’m leaning heavily towards Model based Authentication. However, your comments are appreciated.