Re: authentication/authorization

On Wed, Jun 08, 2005 at 01:35:16AM +0200, Frank Tegtmeyer wrote:
> Jacob Smullyan <[email protected]> writes:
> All proposed things sound like never used - didn't you or anybody else
> implement something related to authorization? If you did, what was the
> approach?

I personally haven't done much with authorization, and what I have
done I've been able to do via some ad hoc scheme, putting the
authorization logic in the components, as you described.  

> > admin_doSomething, guest_doSomething, friend_doSomething, etc.
> > callComponent could again be decorated/replaced so that you just call
> > <:component doSomething:> and the correct real component is
> > dispatched
> 
> This looks more like a thing I would like. It seems to be flexible
> enough to provide all that is needed.

This shouldn't be hard to do.  It would involve a configurable way for
the alternate- or sub-components to be located; a configuration
variable that would default to a function that looks in a subdirectory
with the component name, perhaps.

In fact, there is a mechanism at the moment, which I seldom use and
hence forget about, that lets you register a component protocol.  The
remote_client service uses it; "cascading" component calls use it,
too.  This is less transparent, in that you have to invoke it
deliberately, but that doesn't seem bad to me:

  <:component authgeneric://path/to/component :>

"authgeneric" would be the protocol, and it would determine the real
component path to execute.  

> > Of course, you could implement everything above AE, without changing
> > the behavior of callComponent, but then you have to restrict yourself
> > to the api you write; that isn't necessarily bad, however.
> 
> How would this be used? A call in every component? 

It would mean that just calling a component would involve no security
check, but that your application code could call secureCallComponent
whenever it wanted.  Using a component protocol would be similar in
effect.

> > What is your wish list for this?
> 
> I didn't think much about it, so take the list only as that what it
> is: some ideas/wishes.
> 
> - Roles/Groups
> - URL/scope based settings for a whole subtree of URLs (in Zope through
>   akquisition)
> - exceptions/override of inherited settings
> - different component output for different Roles/Groups
> - settings fixed (no change possible during runtime)
> 
> > In a few months I'm going to shift
> > my focus to skunk4, and maybe it should make this sort of concern more
> > central than it has been heretofore.
> 
> This sounds good, I hope to get some insight into skunkweb again and
> possibly Zope3 also. I would like to help - even with some stupid
> questions :)

Excellent!  Soon I hope to start a conversation about what a good
direction would be.  I have some ideas and some code.

j

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCplYxuqamFyFXXLIRAiOpAJ9DhKIA2tcN0w8yYtLHfot1ApfwGwCfYYmf
8cdS/JRVT5aZhT4/Q0GJVaw=
=WIw1
-----END PGP SIGNATURE-----