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!
I originally thought rm-level auth was a bad idea since you should group the run modes into an application module that is used by the same type of user. I can however see why you might want to group several run modes that deal with the same data type together... but I'm still not totally convinced. Anyone else have any thoughts on this? I just always do module level auth and then never have to worry about securing individual run modes, just the app module.
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.
Now, this is where I definitely disagree. It's so easy for me to use mod_perl authentication (especially using C::A::P::Dispatch). You can be as granular or as top-level as you want. I just don't understand the ISP argument since root level servers are just $30 a month. That's serveral dozen low traffic domains. Or one or two mid level. If you don't want to deal with complete machine control, you can have virtual servers starting at $15 a month.
With prices like that I just don't understand why more people don't just use the power of mod_perl.
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.
Going back the question above about rm-level auth. If you abstract your CRUD functions to your DAO (Class::DBI, etc) then having you can still reuse the majority of the code and templates.
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.
This can still be done even if the authenticated portions are in another app module. The auth we still redirect them to the sign up page.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- 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]
