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]