On 4/3/06 8:33 AM, "Michael Peters" <[EMAIL PROTECTED]> wrote:
>
>
> Michael Lackhoff wrote:
>> On 31 Mar 2006 at 12:18, Jesse Erlbaum wrote:
>>
>>> One other note, on which I have been harping for years: If you are
>>> about to tell me that you can't have a separate instance script for each
>>> application because your login system would have to be duplicated in
>>> each application, then you're doing things wrong. Authentication and
>>> authorization belongs in Apache -- not in your CGI-App module.
>>
>> No, this is not the reason, why I want to split my application but
>> still, I am not convinced that authorization belongs in Apache. Say I
>> have an application with a company and branches. Now I want that a user
>> is only allowed to run the runmodes with data of the brach the user
>> belongs to.
>> This info is within the application and Apache doesn't know anything
>> about it -- at least if I don't want to duplicate my branch layout in a
>> htgroups file or similar.
>> Or if this case is still simple enough that with some tricks Apache can
>> use the info in the database, what about special cases where a user is
>> granted rights just for part of the info, say anything, except sallary?
>> The 'knowledge' about the different roles of users is inherently within
>> the application and I cannot see how Apache can do really flexible
>> access restriction without being part of the application.
>
> Even the most complicated auth setup can be done in Apache using
> mod_perl Authz and Authen handlers. Even though it's running at the
> apache level, it's still a part of your application since it's
> connecting to your database and has your business logic. It's just done
> before your application has a chance to run.
Just to add a bit here:
Apache2 (and Apache1.3) includes handlers that divide the request/response
cycle into phases (http://apache.perl.org/docs/2.0/user/handlers/http.html).
CGI-applications live under the PerlResponseHandler. Note that there are a
number of other handlers, and they are designed to be used. Under mod_perl,
each of these handlers is accessible and truly can be useful, using only
perl. It really isn't orthogonal to good CGI::App design to use these other
phases of the request/response cycle if you are under mod_perl and have
access to them. Doing so can actually lead to tighter, more reusable, more
easily maintainable code, rather than less.
As for business logic and fine-grained auth/authz, that can be incorporated
in arbitrarily complex ways using the apache auth/authz handlers coded in
perl. Imagine, for example, making a simple YAML file that includes
runmodes followed by groups allowed to access them. Then, you could
probably rather easily write up a perl handler that is fully general that
allows you to specify a YAML file for each webapp. Changing the YAML file
would offer any granularity for any website you care to create. A
PerlSetVar could allow you to set the DB from which to grab information and
you are up and running. When you design another webapp using CGI::App, you
just write another YAML file as needed, use the same database (or a
different one), etc. And, now you decide that RDMS isn't the way to go, but
LDAP is, just alter your authen/authz handler slightly, and you are
off-and-running. Perhaps most importantly, you can move an application over
to Catalyst and the authen/authz doesn't need to change. And static content
can be protected easily as well.
Sean
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
