Hi! Regarding your reason to write your own Auth-module, there is a POST_LOGIN_CALLBACK. You can use this to do all the custom stuff you want to do, that CAP::Auth doesn't do. Using a session, you can store a whole bunch of things.
Concerning the mixed runmode thing: I wrote a small bulletin board using CA::Dispatch, CAP:Auth and CAP::Authorize, and I used a predefined guest account to implement this mixed auth feature. In conjunction with CAP::Authorize, the guest has limited privileges and can't access all runmodes, a regular user can. I use a bunch of modules, but not necessarily to separate auth with non-auth runmodes, but to split up the tasks according to this tutorial: http://docs.google.com/Doc?id=dd363fg9_77gb4hdh7b Some other, probably OT thoughts on mixed/auth applications: A design problem I have is, to share data between auth runmodes and non-auth runmodes. E.g. data means the content of the navigation. Example: Navigation before login: - home - topic - login - register Navigation after login: - home - topic - secret area - logout How did you plan to do such thing? HTH, Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of P Kishor Sent: Donnerstag, 4. Juni 2009 19:40 To: CGI Application Subject: [cgiapp] designing a mixed open/protected application Perhaps a basic question on design and organization, but reading some of the articles online hasnt been sufficient for me, so I pose my query here. I am developing an app that will have both open and login content. All my apps until now have had one instance script and one module, but now I am thinking, could I benefit from having multiple instance scripts with their own modules? open.cgi Open.pm http://example.com/open/view http://example.com/open/map .. and so on loggedin.cgi Loggedin.pm http://example.com/loggedin/login http://example.com/loggedin/view .. and so on Does the above seem reasonable? Now, re. the authen mechanism. I tried Cees Heks Plugin::Authentication and found it very easy to implement. However, I am still thinking of rolling my own because I want to extend the authentication mechanism to store extra values as user preferences, and Plugin::Authentication seems to have sufficiently complicated innards to dissuade me from opening it up and trying to understand it. Nevertheless, I have two questions -- How do I indicate that specific runmodes are protected and require login? (mixed mode) How do I set aside an entire module (for example, loggedin) to be protected? (all or nothing mode) Any other advice, pointers would also be very welcome. Many thanks in advance. -- Puneet Kishor http://www.punkish.org/ Carbon Model http://carbonmodel.org/ Charter Member, Open Source Geospatial Foundation http://www.osgeo.org/ Science Commons Fellow, Geospatial Data http://sciencecommons.org Nelson Institute, UW-Madison http://www.nelson.wisc.edu/ ----------------------------------------------------------------------- collaborate, communicate, compete ======================================================================= ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ Eingehende eMail ist virenfrei. Von AVG überprüft - www.avg.de Version: 8.5.339 / Virendatenbank: 270.12.53/2154 - Ausgabedatum: 06/04/09 05:53:00 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
