[Zope3-dev] Problem granting to principals

[Jim Fulton]

Roger Ineichen wrote:
> 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?

PAU is obscene in Portuguese. :)

Anyway, perhaps we should just use PAS.  Then the "S" will be
meaningless in both the Zope 2 and Zope 3. :)

>>My suggestion is that we make plugauths folders that hold plugins.
> 
> 
> Inherit PluggableAuthentication class from BTreeContainer
> and implements(IPluggableAuthentication, IAuthentication, ISourceQueriables,
> IContainer)

Yup

>>They would grow a "Plugins" tab. 
> 
> 
> Register contents.html view under the name Plugins.

Yup

>>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) 

Right, except we'd use the less error prone syntax:

    contains(IPlugin)

Your example above illustrates why we switched to a simpler syntax. :)

>>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)?

I think that would be too indirect.

I think we want the user to be aware that they are
registering.

Maybe it would be best to just include that information in
the add form.

> 
> 
>>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

yes

> - the name (object.__name__) used in the folder (plugauth/PAU)

And we say that, if they ommit it, the registration name will be
used.

> - the status where the utility should have after adding

Yes

Also, for some plugins, the prefix, which defaults to the registration
name plus a dot

> - the interface whcih should be used for utility registration
>   (I don't like this, perhaps we register on a default interface)

Me niether.  I think Stephan did something interesting to
help this on his branch.  I suggest we look at that when it has
landed.

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

Because, in general, we can't know which interface the user will
want to use.

> 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.

Right, but it can be hard to predict which interface, among
those provided, which one should be used.  If a component
provides a single interface, then that is the logical default
choice.  This is complicated by the fact that we currently
make components offer ancillary interfaces to satisfy the
framework. These ancillary interfaces confuse the interface
selection.  This is why, for example, the utility registration
for PAS offers the incorrect ILocalUtility as the default.
I think Staphan's changes might fix this.

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

Yup

> 
>>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.

One suggestion:

List the principals for which there are currently grants,
with rows for principals and columns for roles.

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

Yes

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

Sure

> 
> 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)

I thought we agreed not to do this. Or maybe I just proposed
it. :)

> - principal to group ( will add principals to groups)

You mean roles (or something we rename) to principals.

Assigning principals to groups is done elsewhere.

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

No, management of what principals are in what groups
is done with the actual group in the group folder.

> - groups to permissions

We should grant roles (or whatever we rename them to)
to groups.

> It's different to what we hae now. I think we have to provide 
> a Access Management UI.

I don't know what you mean by an "Access Management UI".

Maybe a mockup of what you mean would make sense.

> 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.

But grants are specific to particular objects.  Group membership is
global.


>>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?

He's doing the merge as fast as he can. :)


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

I don't think they need to be backward incompatible.
All you are doing is adding folder functionality to PAS.
That needn't break existing functionality. You are changing the
add views for plugins. That shouldn't affect existing instances
or registrations.

> Or is somebody uesing the authentication package in production?

People are using it actively for development.  My recent changes
caused Marius some pain.

> I preffere to add abranch for this work. This way we can share
> it an tryout some usecases.

OK

 > I think I will need your help
> during the refactoring.

Keep in mind that my time is very short, as you can tell, given
how long it's taking me to review the File work. :/

Jim

-- 
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