Hi Stephan and Jim

Here my mail where I promissed to write.

This mail describes a broken combination of common zope3 components.
And I propose to use trusted locatable traversal adapters since they 
are the only solution where I can see for a bugfix right now.

First the component I'm talking about:

PAU - pluggable authentication utility

Site - ISite implementations 

Security - the default security implementation in zope 3.
           e.g the canAccess and canWrite method and the security proxies.

If we setup a site with a local PAU, we can offer a login for users where
defined in the PAU. This is the standard way, except if you define users in
the ZCML (global).

Now it's possible to setup a site for a company where they will use as a 
extranet. Then we can setup a second, nested site (sub-site) which is a 
section where customers of the company have access to. But the customers 
don't have access to the parent where is the extranet.

Setup a site and a sub-site. Add on each site a PAU. Add in the first
site the principals of the company and add in the sub-site the customers
principal. Now if you try to access the sub-site, you see, that you are 
not able to access the sub-site because you can't travers over the first 

This means, we only can use nested sites if you are allowed to traverse
over the first site.

There is solution for this restriction. We can register the traversal 
adapters trusted and locatable. This makes it possible to let  
everybody travers to the sub-site and use the login there.

Why do I propose that?
Trusted locatable adapters are a solution where will fix another issue.
The real problem with untrusted travesal adapters and different PAU in 
sub-sites has to do with the security settings lookup for proxies.
But I'm not really sure where the problem is located. 

If a principal is defined in the site and has permission to manage 
principals on the site level, everybody excepts, that this principal
can manage principals at the sub-site level too. This is how the normal 
permission inheritation works in zope3. 

A complex, broken usecase
The principal in the site has only ManagePrincipal permission for 
the sub-site. This can be done with grant the permission on the 
sub-site. Now we write a view where a user can manage principals
and define for this view the ManagePrincipal permission.
This view is usefull since we don't allow users to access the 
++etc++site space. 

Normaly we have to grant the ManageService and ManageSite permission
also for manage principals. But we use removeSecurityProxy in the 
view where we use to manage principals, since we don't like to give
principal manager give access to the site directly. 

Now, if a principal defined in the site will manage principals
in the sub-site via the custom view where we remove the securtiy
for the principal folder and all required components where he 
normaly can't access, we run into a unauthorized exception.

If we define the principal in the sub-site and use the same view
for manage principals it doesn't raise a unauthorized exception.

The reason why?
I'm not sure why this happens. I'm only sure that the permissions 
are correct since I only grant the princial to a custom role. This 
means I defined a role in the site where has the permission to manage 
principals. If I grant this role to a principal in the site level 
it doesn't work and if I grant this role in a sub-site it works.

It also works for both use cases if I register traversal adapters.

What's the problem?

I'm not sure which part is responsible for the unauthorized error
where the principal form the site is running into. 

The following component can be responsible:

a.) site hook where doesn't get the right PAU and force to
    use the global principal settings

b.) the permission setting lookup used for check the permissions 
    for proxies. (canAccess or canWrite method)

I'm only sure that a adapter forces to lookup security permission
and this ends in useing the no location which ends in lookup
the global permission seetings for the principal.

btw, we whouldn't have all this problems if adapters where locatable
by default. By allt his errors I mean loosing the location by lookup
the permission.

The nested site setup is broken if not useing locatable traversal adapters. 
And I think the permission lookup concept should be different implemented 
since there is so much potential to run into missing location problems.

Jim, btw,
a locatable, trusted traversal adapter implementation doesn't mean we 
offer a introspection in general of sites structure. 
For avoid the introspection of site struture, we can do the following:
Only show a "404 not found page" for logged in users. If a user isn't logged

in, we can show the "login page". With this concept, there is no way to
introspect a site structure because you allways get the "login page".
Of course this will end in login for to see that the URL wasn't correct.
But that's a way for disallow the site struture introspection for
not logged in users. Right now we do this with redirecting to the site 
root and if a user get looged in we redirect to the "camefrom". I think
we can offer a better concept with the two level "error" pages like 
described above for trusted traversable sites.

Roger Ineichen
Projekt01 GmbH
Langackerstrasse 8
6330 Cham
phone     +41 (0)41 781 01 78
mobile    +41 (0)79 340 52 32
fax       +41 (0)41 781 00 78

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to