I use Apache/mod_perl to handle authentication as Jesse suggests, but to
handle authorization I basicly use multiple instance scripts for the same
CGI::App.  To use Jeff's example, I would set a CGI::App param called
'admin' to 1 in the instance script that lies in the 'wheel' directory.  In
the 'users' directory, the 'admin' param would be set to 0.

This allows me to have CGI::Apps grouped by functionality,  with only
minimal authorization logic.

I consider this a compromise solution.  It has worked fine, although based
on the current debate I'm not sure if it is the best or worse of both
worlds.

-Will

----- Original Message -----
From: "Jeff MacDonald" <[EMAIL PROTECTED]>
To: "Brian Parker" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 04, 2002 8:32 AM
Subject: Re: [cgiapp] Sessions and Permissions


> Hi,
>
> This is what i do, for what it's worth
>
> Each user group has it's own directory
> Groups behave similar to unix groups
>
> so i may have
>
> htmlsrc/wheel/menus/mainmenu.html
> htmlsrc/wheel/menus/widgetmenu.html
>
> htmlsrc/basicuser/menus/mainmenu.html
> htmlsrc/basicuser/menus/widgetmenu.html
>
> etc..
>
>
> On Thu, 4 Apr 2002, Brian Parker wrote:
>
> > I've been meaning to ask about this since I read Jesse's article on
> > 'perl.com'.  In the article Jesse mentioned his preference for
> > controlling login security and sessions at a layer outside of CGI.
> >
> > I like this idea, because life is complicated enough with having to deal
> > with these things.  But it seems like your CGI-App or at least your
> > template has to have some idea of security, because if a user does not
> > have permission to 'add_widget', I don't want to even show her the link
> > on
> > the nav bar.  In other words, the template must have some idea of what
> > options that user has available.  How have people dealt with this?
> >
> > regards,
> >
> > Brian
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Web Archive:  http://www.mail-archive.com/[email protected]/
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> Web Archive:  http://www.mail-archive.com/[email protected]/
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/[email protected]/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to