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]
