RE: [cgiapp] Anyone used mod_auth_pg?
Hey Mark -- Jesse has written on a number occassions about the merits of handling authentication for web applications at a level seperate from the application logic. While this system appealed to me, I could see how it do it without using mod_perl. Today I ran across another possible solution, The Apache mod_auth_pg module. It allows you to tie .htaccess files into a Postgres database to handle user authentication. The mod_auth_pg module works *exactly* in the same fashion as I recommend. This module is an Apache handler written in C. A similar Apache handler, written in Perl, is Apache::AuthCookieDBI. Apache::AuthCookieDBI also has the capability to connect to *any* database -- not just PostgreSQL. It is important to note that both modules, mod_auth_pg and Apache::AuthCookieDBI, function in EXACTLY the same way even though they are written in two different languages. They are both Apache handlers which tie into the Authentication and Authorization phases of the Apache request. Both of them use the Apache API. Apache::AuthCookieDBI accesses that API via mod_perl, and mod_auth_pg accesses that API directly -- but the code is strikingly similar. For instance, to actually set the user name, here is how the respective handlers perform the task: mod_auth_pg: conn_rec *c = r-connection; c-user = str; Apache::AuthCookieDBI (via Apache::AuthCookie): $r-connection-user($auth_user); Apache::AuthCookieDBI is hardly the only CPAN-based module which performs this task. When I do a search on CPAN for /Apache::.*Auth/ I get **51** modules! I would bet that there are even better modules which do exactly what you want. In addition, it would not be hard to write your own Auth* module. Using Apache and mod_perl, you could write a simple Auth handler which implements all the functionality of mod_auth_pg, with ease. The mod_auth_pg.c code is about 500 lines. Based on the functionality, I would bet you could replace all that functionality in about 100-200 lines of Perl code. (It is a *very* simple module!) I'm not trying to talk you out of using mod_auth_pg! I just want to make sure that everybody understands that what mod_auth_pg is doing is exactly what mod_perl is intended to allow you to do in Perl. Naturally, C code will run faster than Perl code, but I think it is a valuable lesson to write the module in Apache/mod_perl in order to better understand how Apache works, and as a result, how web-based Authentication and Authorization works. The performance in Perl can be excellent, and only a very highly-vistited site would absolutly require Auth* rewrite in C. And if the time comes when you need the added performance of C, your Perl Auth* module often translates line-for-line into it because of the common Apache API. A Perl Apache handler will take you quite far. TTYL, -Jesse- - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] mod_auth* modules require pop-up boxes?
On Wed, 1 May 2002, Jesse Erlbaum wrote: Out of curiosity: How many people here would be interested if I were to release some version of my Auth* modules to CPAN? I'm not very familiar with most of the 50 or so Auth* modules already there -- is this something which would be of value to many people, or only a couple? I'm interested, especially if it an work outside of mod_perl. Thanks! -mark http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [cgiapp] mod_auth* modules require pop-up boxes?
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]
RE: [cgiapp] mod_auth* modules require pop-up boxes?
On Wed, 1 May 2002, Jesse Erlbaum wrote: Out of curiosity: How many people here would be interested if I were to release some version of my Auth* modules to CPAN? I'm not very familiar with most of the 50 or so Auth* modules already there -- is this something which would be of value to many people, or only a couple? I'm interested, especially if it an work outside of mod_perl. Thanks! -mark http://mark.stosberg.com/ I know it's poor etiquette to just to write to say Me too, but since it was asked for, Me too. Mike G. - Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]