Hi Eric -- > Does your Auth module authenticate to the runtime level > (action) for > each user? > > Often the client wants the capability to restrict users > of a group to a > smaller set of group actions. In turn, I've moved > authorization into the > application using a joined user table and the user_action > table (user_id, > action_id) to select permissible actions.
In short, no -- our Auth* handlers only go down to the level of URLs. (What follows is totally off-topic, and entirely IMHO! YMMV!) To me, this is a simple question of granularity. The Auth* handlers we use operate at the level of URL granularity. You seem to want to go further and reach beyond URLs, down to the level of CGI form variables. When I say that you are going down to the level of URL plus form variables I mean that you are adding the "run-mode" table to your list of so-called "actions", as opposed to your set of "actions" being a set of URLs (directories, CGI-App instance scripts, etc). By doing this you are effectively scoping your security at the granularity of a particular CGI-Application instance script (the URL -- which points to a module containing a set of run-modes) *AND* the value of the "mode-param" (usually the "rm" CGI form parameter). IOW, URL plus CGI form parameters. I think going to the level of URLs *PLUS* CGI form variables is a mistake. Think about it: Where do you draw the line? Do you consider *ALL* form variables, or do you just consider a select few (or one)? Do you have a convention for naming run-modes across application modules, or is your whole site a single "Mega-Module"? (And if you have one big "Mega-Module" running your whole site, how is this different from using a "Server-Page" system?) I find that scoping security at the level of a URL is unambiguous and easy to understand. It encourages proper sizing of Application Modules (big enough to do something useful -- not "Mega-" sized). It allows you to group functions by application modules and instance scripts. Furthermore, Apache, and all other web servers, are very oriented towards URL-based configuration. Consider Apache's <Files>, <Directory>, and <Location> directives. Consider off the shelf web-traffic reporting tools! (They specialize in tracking URLs, but not form variable values.) All these existing tools and devices operate at the URL level. Orienting your architecture towards URLs instead of URLs + Variables allows you to further leverage your investment in your web server, your reporting tools, and all their combined capabilities. Doing so will give you a considerable tail-wind when it comes to developing applications quickly, because all the systems upon which you are building are oriented towards the URL, but not form variables. That said (whew!), there very well may be ways to extend and connect CGI::Application's run-modes into some security system -- but it must be very carefully thought out! The beauty of the Auth* architecture we use here is that it not only works with CGI::Application, and it not only works with HTML and other static documents -- BUT(!) it works with ANY OTHER APPLICATION ARCHITECTURE! I could easily combine the system I just described with any or all of the following architectures: * CGI::Application * HTML, images and other static documents * HTML::Mason * EmbPerl * PageKit * AxKit * ASP(!) * JSP(!!) * Java Servlets (!!!) * Cold Fusion (!!!!) * Anything else! Not only would our Auth* system work with any of these types of content, but our Auth* system would happily allow all of these types of content to co-exist on the SAME web site, if you so desired, without any modification. This works because there is a clean line between security at the Authentication and Authorization layers of the request, and the application layer. The security layer doesn't care what the application is written in, because it only cares about URLs. The application doesn't care, because it knows that if it is called, the security system has already has its say: The request has been authorized long before the app ever runs, no matter what language that app is written in. TTYL, -Jesse- Jesse Erlbaum, CTO Vanguard Media http://www.vm.com 212.242.5317 x115 [EMAIL PROTECTED] --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
