Re: Re: Re: Re: Why CGI::Application?

[t'mo]

I like the idea of composing subclasses of C::A into the larger application, but I didn't see how you implemented this bit of the 'technical specification':

"...so it's easier to just disallow the whole C::A than it is to disallow certain run-modes."

If REPORTS => reports.cgi is in the navigation template on every page, then how do you prevent the user from executing that particular C::A? And I don't think that

  # Display some method of choosing reports, probably with some author
+ization
  # checks in there

inside sub choose counts; it's still disallowing a certain run-mode named "choose". :-)

p.s. I enjoyed and learned something from being sidetracked by http://www.mail-archive.com/[e-mail]/msg00849.html.

[dragonchild]

It all depends on how your authentication method is set up. I'm still a little fuzzy on all the details, but you can do a few different things. Each has its own pros and cons, and some combination is probably best.
1. Each C::A could authenticate itself against a master set of authorities. The C::A would implement a check against a set of authorities the user must have. The link would exist, but the user wouldn't get very far.
2. If you're using TT or Mason, you could pass in a $user object and have it determine what links are available, based on the $user object. (Not C::A specific, I know, but not everything is implentable in C::A, nor should it be.)
3. Instead of the $user knowing what links it can go to, you would have the C::A indicate what authorities are needed to get to it. Then, it would register with some master and the $user / TT / something would ask that master where it can go.

And, I'm sure I'm missing other possible schemelets.