On Fri, Jun 5, 2009 at 9:06 AM, Alex <[email protected]> wrote: > 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?
I can do it either on the server side, creating a menu string that goes to one single template, or use two different templates, or I can do it on the client side with <TMPL_IF logged_in>...<TMPL_ELSE>...</TMPL_IF> > > 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 hasn’t 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 Hek’s 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/ ## ## ## ################################################################
