The Update Protocol
In Tapir User Manager, we group form processing code that updates the database into methods titled update.php, that handle a number of forms and actions.
The reason for this is twofold. First, TUM operates under a split-privlege model. Two database users are created, one for read-only access to the database, and one for write-only access. (Note, that read-only access does allow write access to session handling table) Code that runs with write access to the database poses a higher security risk, and is more likely to harbor serious race conditions. By putting it in one place, we can keep an eye on it.
A second advantage is that, after processing a form, the update method directs the browser to a page specified, by URL, in the tapir_dest form variable. This means that TUM can have a smarter user interface than is typical on the web.
Suppose, for instance, that a user wants to navigate from page A to page B...
A ----> B
If the user needs to log in, something like the following happens:
A ---> [B rejects user] ---> login-form.php ---> login.php ---> B
|------- B is stored in tapir_dest-------------|
Note, we can apply the same strategy when a new user logs on -- many
sites dump the user in an awkward place after they register, or after
they click on a confirmation URL sent to them via e-mail. By storing the
location that they were at, we can put the user back in the right place
in the system.
Actions must be coded so that a form can invoke different actions depending on which submit button was pressed:
It would be nice to do something like
<INPUT TYPE="SUBMIT" NAME="action" VALUE="add-user"> <INPUT TYPE="SUBMIT" NAME="action" VALUE="pet-cat">
But the VALUE is also the label of the button. That means, if we change the label of the button, we have to change update.php to recognize the new label. This is a problem if:
(1) We want change the name of the button to make the page more usable
(2) We want to internationalize
(3) We want two buttons in the form to have the same label (but have their
function distinguished by physical location)
SUBMIT buttons need to look like
<INPUT TYPE="SUBMIT" NAME="action-add-user" VALUE="Add User"> <INPUT TYPE="SUBMIT" NAME="action-pet-cat" VALUE="Pet Cat">
The update method scans the form variables, looking for one of form "action-", it then interprets the remainder of the string as an action.
Note: a shortcoming of the current design is that it doesn't provide a simple way that a site can override just one action handler. It ought to be possible to use OO-techniques (put all the action handlers in an object, and create a hook that lets sites subclass the object)