David Nicol's story about using cookies for the help desk seems like a
reasonable strategy, and (perhaps to his surprise) I don't feel that
kernel-protected capabilities are necessarily required for that
application. It depends mostly on what the help desk application lets the
user do.
A couple of thoughts on that application, though:
You might want to have a look at Tyler Close's droplets architecture
(contact tyler@waterken.com). It provides a way to build capabilities into
URLs, which is nice in your application. You can imagine generating a URL
for a form (one that becomes unusable after a limited amount of time)
Another thought concerns cookie theft. As long as your help desk machines are reasonably well isolated from the users, cookies may be a fine solution. The main problem I see is that cookie flies are just text files, and any idiot can extract the cookie and hand it to someone else. If your goal is to avoid excessive abuse of the help system, but you are willing to tolerate a little bit of abuse, then cookies work fine. If the help desk facilities include sensitive features, such as the ability to change someone's password, then I think you will want to require the help desk person to log in. Don't give up the cookies, as you still want to narrow the locations from which this can be used. They aren't perfect, but they do help.
In any case, good luck with your application.
Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 6576