[cgiapp] designing a mixed open/protected application

[Alex]

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: cgiapp-bounces at lists.openlib.org
[mailto:cgiapp-bounces at lists.openlib.org] 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://lists.openlib.org/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://lists.openlib.org/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