"You could extend your idea by simply attaching a privilege set to the user. You set up your privileges in your pre-run logic.
Whenever someone hits a run time that requires some privilege have it test for it. ..."
In my real-world project that is exactly my intention :-)
"It would be easy tie this with CGI::Session ..."
But instead of using sessions and managing the privilege sets myself, I plan to rely on the webservers and OS's access control mechanism. It's going to run under NT with IIS, as one of the requirements is to use existing NT accounts.
"However, I prefer to separate admin and user functionality. So while you may have users who may do things (requiring privileges) ..."
You hit my intentions again, in my real-life project I need user functionality requiring privileges (thanks for the good wording :). The project is ment to demonstate a web-app which fully supports the required workflow/process (and thus eleminating a lot of manual work). It's about a "anonymous" user submitting a request, which will need to be linked to the existing helpdesk system, then to be approved (or rejected) and finally implemented whislt keeping the original requestor updated on progess.
So I have to separate funtionality for at least these groups: requestors, approvers, implementors as well as auditors and administration. The last two groups are my candidates to get completly separated, while the other groups basically have the same run_modes plus some group depending add-ons (like the "approve/reject/implement" buttons).
I plan to disable anonymous access to all priviledged instance scripts for the authentification and then use file system permissions to handle the authorization.
The guestbook example was more the try to cut the problem down to the essential part (adding those small bits and pieces without having to write additional run modes).
"Hope thats a useful slant on what you have."
It definatly is!
| [reply] |