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
are
defined in the PAU. This is the standard way, except if you define users in
the ZCML (global).
Usecase
-------
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
-----
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
site.
This means, we only can use nested sites if you are allowed to traverse
over the first site.
Solution
--------
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.
Usecase
-------
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.
Fazit
-----
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.
Regards
Roger Ineichen
_____________________________
Projekt01 GmbH
www.projekt01.ch
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
email [EMAIL PROTECTED]
_____________________________
END OF MESSAGE
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
