RE: [cgiapp] How to split runmodes into different modules
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. Cheers, Michael - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
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. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
On 3 Apr 2006 at 8:33, Michael Peters wrote: 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. Hmm. And how do I tell Apache that two users are permitted to view a certain runmode but only one of them may see all the info? e.g. in a template: pSome normal stuff/p [% IF user_is_in_group_x %] divFor your eyes only/div [% END %] The alternative would be to give both of them different run modes that are almost identical. And if I want to give it a try, where can I read more about these Auth* handlers? Cheers, Michael - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
Michael Lackhoff wrote: On 3 Apr 2006 at 8:33, Michael Peters wrote: 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. Hmm. And how do I tell Apache that two users are permitted to view a certain runmode but only one of them may see all the info? That's a good question. I'm not convinced that this needs to be at the apache level, but it certainly could be. You could either create a subclass of the normal application that has the privileged stuff turned on, or simply create a new instance script (or dispatch rule if you're using C::A::Dispatch) which passes a privileged param into the application. Then use Apache to restrict access to that new instance script (or URL if you're using Dispatch). e.g. in a template: pSome normal stuff/p [% IF user_is_in_group_x %] divFor your eyes only/div [% END %] You could even use the same template for both instance scripts/application modules in either of the above approaches. And if I want to give it a try, where can I read more about these Auth* handlers? http://www.modperlcookbook.org/chapters/ch13.pdf http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthzHandler http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthenHandler Good hunting. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
On 4/3/06 9:19 AM, Michael Lackhoff [EMAIL PROTECTED] wrote: On 3 Apr 2006 at 8:33, Michael Peters wrote: And if I want to give it a try, where can I read more about these Auth* handlers? This book chapter was written for apache 1.3 and mod_perl 1, so some of it might need some translation to mod_perl2 and apache2, but I hope will get the idea. http://www.modperl.com/book/chapters/ch6.html Sean - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
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/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Michael --
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.
Good questions!
Let me start by separating Authentication from Authorization. The
former is the means of identifying the user who is logged in. The
latter is determining if that user is allowed to do a particular thing.
That being said, I think we can all agree that the means to determine
the identify of the user doesn't change at the application layer, and
may be entirely implemented in Apache. That leaves us with
Authorization. Authorization happens in many ways. There is general
authority, and there is the sort of fine-grained authority you refer to
in your message.
General authority might refer to whether a user is an anonymous public
user, a logged-in user, or an administrator. Tao Apache might suggest
that any request to the /admin/ directory require that the user is an
administrator, otherwise they are redirected to another page. Perhaps
only logged-in users (or administrators) may access the /membersonly/
directory.
This is the type of security for which Apache was designed. Apache's
whole security model is based on paths. Using the Location directives
(or .htaccess files) and require group directives you could easily
configure this type of general security. If you judiciously make use of
CGI-App instance scripts, as I described in my last message, you can
combine that with Apache's security philosophy to achieve probably 80%
of what you need.
That leaves the last 20% of the picture: Fine-grained authorization.
You describe situations where a user might not see a particular column,
or not be allowed to change a particular field. Once you get to the
point of contending with fine-grained security, you generally have to
add this code to your application layer.
Fortunately, you already know who the user is, and know that they are
allowed into the application. You only need to make very specific
tactical decisions. Your code can refer to the REMOTE_USER environment
variable with confidence that it is populated with a valid user. If you
have programmed your Apache Authorization module to do so, the user's
detailed authority settings may already be in the environment,
permitting you to know what fine-grained authority the user has without
the need to query a database again. All you have to do is:
show_delete_button() if ($ENV{USER_MAY_DELETE});
If you take the time, you could even centralize this logic in Perl
modules and in your HTML template layer. In Krang, for example, we use
a strict Model-View-Controller architecture. In the Model modules we
query the user's permissions to determine if they are permitted to edit
the particular object (e.g., a Story object in a particular category)
they are trying to edit. If the user attempts to save() or delete() an
object they are not permitted to edit, we throw an Exception::Class back
to the CGI-App (Controller), which is then caught and conveyed into
action: an alert to the user, entries in the security logs, etc.
Designing a system like this takes time, but it pays for itself ten-fold
in extensibility, reliability, and ease of future development.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
Michael Peters wrote: 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. Sounds interesting. Any chance you could post - or point to - an example of how to get started with that sort of thing? -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Richard -- Sounds interesting. Any chance you could post - or point to - an example of how to get started with that sort of thing? I got started by reading the source of Apache::AuthDBI (part of the Apache::DBI package). In Apache::AuthDBI you will see the essential ingredients of a custom Apache Auth* module. -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
On 31 Mar 2006 at 8:25, Michael Peters wrote: The only difficulty is, if you want a cross-sub-application connection not by a link but through a form submission. That was my problem the other day. Form submissions should be no different than links. You just point the form's 'action' attribute at the same url that the link would go to. In a sense you are right, of course, but in a sense it is different. In my example I want to save a record and after the save show a menu page. If I used the menu runmode as the form action for the save (and several other actions that all come out at this menu), things would get really messy. It works just fine for our stuff, and it can get pretty big. If you want a working example, check out Krang (http://krang.sourceforge.net). It's one really big CGI::Application. I downloaded it once but it was too big and complex for me to understand what is going on -- at least at that time. Perhaps I should have a fresh look. Thanks, Michael - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
Michael Lackhoff wrote: I downloaded it once but it was too big and complex for me to understand what is going on -- at least at that time. Perhaps I should have a fresh look. Another one you could look at is Smolder (https://sourceforge.net/projects/smolder). It's much smaller and simpler than Krang, but... it means I'm tooting my own horn :) -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] How to split runmodes into different modules
Hi Michael Michael -- If you want a working example, check out Krang (http://krang.sourceforge.net). It's one really big CGI::Application. That's not true. Krang is not one big cgi-app. Krang is actually composed of multiple, separate CGI::Application modules, each launched via their own instance script: htdocs/media.pl htdocs/history.pl htdocs/about.pl htdocs/schedule.pl htdocs/my_alerts.pl htdocs/category.pl htdocs/desk.pl htdocs/story.pl htdocs/media_bulk_upload.pl htdocs/workspace.pl htdocs/bug.pl htdocs/debug.pl htdocs/site.pl htdocs/status.pl htdocs/publisher.pl htdocs/group.pl htdocs/env.pl htdocs/user.pl htdocs/help.pl htdocs/my_pref.pl htdocs/desk_admin.pl htdocs/contributor.pl htdocs/login.pl htdocs/template.pl htdocs/list_group.pl These separate applications are tied together (in some cases, very tightly) to produce the effect of one big application, which is the goal for any project, I imagine. This is done through links, sessions, centralized security, and clear-headed thinking. I do strongly agree that Krang is a good example of the use of CGI-Application. (And I'm not just saying that because I helped design it!) We spent time to thoughtfully consider what run modes belong in which applications, and how they should function together. One example of what is possible with this architecture is the add_message facility. (This elegant system was designed by Sam Tregar.) By cleverly using sessions and a custom CGI-Application parent class, the developer can easily send a message to another page, even if that page is in another application. For example, if you save a story you are redirected back to your workspace with a message at the top of the screen, Story XYZ saved. I'm obviously a proponent of the organizational scheme Krang uses. As far as multiple instance scripts: The idea is that each script (really, each URL -- that is the main purpose of an instance script) represents an entry point into a task. You could type in the URL of the instance script and begin a task. It's a point of looser coupling. IOW, the run modes *within* one CGI-App are more closely related to each other than to a separate CGI-App. This idea is core to the philosophy of CGI-Application. If you don't believe in this philosophy, I think you might find that a server page system will work better for you. 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. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] How to split runmodes into different modules
Jesse Erlbaum wrote: Hi Michael Michael -- If you want a working example, check out Krang (http://krang.sourceforge.net). It's one really big CGI::Application. That's not true. Krang is not one big cgi-app. Krang is actually composed of multiple, separate CGI::Application modules, each launched via their own instance script: I didn't mean it literally as one big CGI::Application based module. I was actually trying to make a pun that loosely meant one really big CGI application that uses CGI::Application. Maybe I should have used a smiley or something to indicate my non-literal intent. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] How to split runmodes into different modules
Hi, My question may sound very basic on this alias but I do need some guidance here. I have seen discussion on this alias about splitting runmodes into different modules. But I still could not figure out how these different modules can be linked together again for the same Application. I have an Application.pm with all the runmodes in Setup() and an Instance Script that has My $app = Application-new(); $app-run(); Now How do I split the runmodes into different modules and what would be my instance script and how do I link all of them together. Can you please point me to any examples or tutorials that can help me figure this out. Thanks Prakash
