Drew and Cees, I am in the process of converting over a non CGA application to run under CGA. (Sort of) does the same stuff as CGA in a non-OO way. My application has implemented user and group authentication and this is what I try to accomplish from a design perspective.
Run mode level authentication is preferable otherwise in your example it looks like you would need separate your non-authenticated run modes out into another CGA module (+ instance scripts etc) even though they are just a different view on of same application model. If you get rm-level security right you get application security for free! A point I would like to add is that the documentation on the wiki strongly suggests doing authentication using the app server and not in your application. This (I think) would not provide the necessary granularity for run-mode level security and also using a consumer(ish) ISP they do not allow me access to httpd.conf to install my own modules etc. Crud checking at the entity being viewed/updated/ for the user since this allows you to re-use the rm code and html template code. E.g. a user can change their own address details but not others, even though they may be able to see them. Think of a user directory kind of thing. In order for users to "discover" more of the site and encourage them to register and sign in then I allow them see links/menu items that when they click on, it "trips" a sign in and then once signed in it redirects them to where they wanted to go through saving path info etc. in a session attribute. I have implemented this in a MyApp:CGIAPP class that provides a standard login-rm that gets triggered if authentiation is required. I'm not sure you need to cover this but I find it is very helpful to "open" sites. I do often wonder whether I should do all my authentication using some sort of generic directory service rather than mucking about with my own user tables, group tables and so forth. Another plugin for your plugin to support directories? O. -----Original Message----- From: Cees Hek [mailto:[EMAIL PROTECTED] Sent: 29 October 2004 07:32 To: Drew Taylor Cc: CGIApp Subject: Re: [cgiapp] User authentication Hi Drew, I have been hinting at an Authentication plugin for a while now, but haven't finished it yet. I did a little bit more work on it yesterday, but I don't have any docs, or any tests written for the module yet. I you also have a start on a module, maybe we can colaborate. From your comments below it sounds like we are probably on the same track... I was planning to use the CAP::Session module in combination with CGI::Session::Auth which is an addition on top of CGI::Session that handles authentication. That is what I use in my apps right now, and I am just trying to abstract the code out into a plugin. Here is an example of how I see it working: package My::CGIAPP; use CGI::Application::Plugin::Session; use CGI::Application::Plugin::Auth; use base qw(CGI::Application); sub setup { my $self = shift; $self->start_mode('default'); $self->mode_param('rm'); $self->run_modes([ qw( default other_runmode ) ]); $self->require_authentication(1); $self->require_authorization('agroup'); } The call to 'require_authentication' makes sure that the user must be logged in to access the runmodes in this module. The call to 'require_authorization' makes sure that the user belongs to the group 'agroup'. So basically you have authentication and authorization on a per module basis (it could probably be extended to do per runmode auth, but I haven't needed that, and think it is probably a design/organizational mistake to do so anyway). The implementation is fairly simple in that a callback is registered at the 'prerun' level that calls $self->auth->authenticate() which tells CGI::Session::Auth to check to see if the user is logged in, or trying to log in by looking at the CGI params. If the user is not logged in (and we require authorization in the runmode) then the user is redirected to a login page. If the user is logged in, but doesn't belong to the right group, then they are redirected to a forbidden page. If at anytime the user loads a runmode called 'logout', then the user is logged out. I am trying to find a way to have this module work in a way that doesn't require any configuration at all (like the session object), but it is a bit more difficult, since it depends on custom runmodes (login and forbidden). And also it would require the login fields to be named correctly. The only way that I can think to do it is to have the plugin add some new runmodes to the module! Does anyone have any suggestions on how to do that cleanly? Is it even wise? Anyway, Drew, if you (or anyone else for that matter) is willing to colaborate on an Auth module, I would be happy to help out. Cheers, Cees On Fri, 29 Oct 2004 01:28:42 -0400, Drew Taylor <[EMAIL PROTECTED]> wrote: > I was playing around with Maypole yesterday as a possible alternative > or addition to CGI::App. There are many excellent features: integrated > support for user authentication, automatic form generation, CRUD > capabilities, etc. For the moment, I've decided that Maypole is not > for me. But I'd like to be able to bring drop-in support for simple > user authentication into a C::A application. > > I'm planning on using Cees' C::A::Callbacks (nice job!!) to handle > adding the appropriate code checks. Anyone have ideas (or code) on > ways to do it in a generic way? I'm thinking of doing it ala Maypole > since that should be relatively easy to implement and seems easy to > specialize in a particular application. > > The way maypole handles user authentication is through the > authentication() method. This simply returns a true or false value. > The default implementation allows all requests. Applications can > define their own ideas for authentication. One authentication module > which takes authentication to the next level is > Maypole::Plugin::Authentication::Abstract. It defines three levels of > authentication (using the session as a stash) > > 1. Public: No authentication, only session management 2. Private: > Authenticate once, go everywhere 3. Restricted: Authenticate and > reauthorize with a ticket for every request (best used in a post form > as hidden input) > > My current plan is to combine the use of C::A::Plugin::Session to do > session management, and add some glue/stub methods for the actual > authentication. Restricted is overkill for me ATM and will probably > not be implemented initially. I'm thinking of calling it > CGI::Application::Plugin::Authentication. All ideas (and criticism) > welcomed. > > Drew > -- > ---------------------------------------------------------------- > Drew Taylor * Web development & consulting > Email: [EMAIL PROTECTED] * Site implementation & hosting > Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres > ---------------------------------------------------------------- --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
