[Zope3-dev] Problem granting to principals

[Roger Ineichen]

Hi jim,

> -----Original Message-----
> From: Jim Fulton [mailto:jim at zope.com] 
> Sent: Thursday, February 10, 2005 1:30 PM
> To: dev at projekt01.ch
> Cc: zope3-dev at zope.org
> Subject: Re: [Zope3-dev] Problem granting to principals
[...]
> 
> Thanks!
> 
> We need a shorter name for pluggable authentication utilities,
> at least when talking aming outselves.  I suggest "plugauth"

I think PAU is Ok, you use PAS also for Zope2's PAU tool and everybody
knows what you mean. Or not?

> My suggestion is that we make plugauths folders that hold plugins.

Inherit PluggableAuthentication class from BTreeContainer
and implements(IPluggableAuthentication, IAuthentication, ISourceQueriables,
IContainer)

> They would grow a "Plugins" tab. 

Register contents.html view under the name Plugins.


> Plugins would be set up to be
> contained in pluauths and plugauths would only contain plugins.

The interface IPlugin is a marker for plugins. We can use
it for to mark plugins like now.

We can use a constraints like:
def __setitem__(id, plugin):
    """Add plugin to the PAU."""
    __setitem__.precondition = ItemTypePrecondition(IPlugin) 


> Plugins would *still* be registered as utilities, but we could
> provide a streamlined registration process.  

Can we use events for register IPlugins if we add them 
in the __setitem__ method of the folder (plugauth/PAU)?


> For example,
> adding a plugin with a certain name would register it with that name
> *and* probably offer to configure it in the plugauth.  

We need a addfrom view with information about 
- the name where the utility is registred
- the name (object.__name__) used in the folder (plugauth/PAU)
- the status where the utility should have after adding
- the interface whcih should be used for utility registration
  (I don't like this, perhaps we register on a default interface)

btw. why do we have to select the interface for utilities if
we register them?

Normaly just one interface is used for getUtility(iface, 'empty or name')
It doesn't make sinn to offer othe interfaces. Or the utility never get used
in getUtility methods writen for this plugin.

Perhaps I have to take a look at stefans branch. 
The registration part I think is different then now.

> This would make plugauths much more like Zope 2 PASs.

Oh, I didn't work with Zope2 since the last 3 Years.

> I'm sure you can think of other improvements to the actual UI.

Just some ideas, doesn't affect our work now
we can make desicions later about this part.....

Yup, I like to get a grant table with simply cols and rows
for granting what ever you like.

I also think it whould be nice to change the search part.

What do you mean about to search source items (hoa many you like)
and then render a grant table with this selected source items


Step 1:
Select principals who many you like.

Step 2:
Select what you like to grant, 
e.g. 
- principals to permission (will give the principal the permission)
- principal to group ( will add principals to groups)

or select groups and grant something with groups like:
- groups to principal
- groups to permissions

It's different to what we hae now. I think we have to provide 
a Access Management UI.
In this UI we can manage the access for principals in each case.

Now we have the management for accessing Zope objects on different places.
And we have different ways to give somebody access.

I like it if we can support a real Access Management UI in one view!

In this concept whold the word grant be wrong.
Its more like manage access where you can do what ever you have to do
for setup principals, groups, roles(privileges) or permissions.



> In any case, I think we shouldn't do this until Stephan has
> had a chance to merge is branch and until we've had a chance to
> recover. ;)

I don't know. What does stefan say?

> Jim

Should this work be backward compatible? I don't think so.
the last changes two weeks ago were not backward compatible.

Or is somebody uesing the authentication package in production?

I preffere to add abranch for this work. This way we can share
it an tryout some usecases. I think I will need your help
during the refactoring.

Regards
Roger Ineichen


> -- 
> Jim Fulton           mailto:jim at zope.com       Python Powered!
> CTO                  (540) 361-1714            http://www.python.org
> Zope Corporation     http://www.zope.com       http://www.zope.org
>