Re: [Zope] Access Control vs Publishing Protoco
Seb Bacon wrote: edit a document through webDAV but *not* TTW. In my mind, you're either authenticated to do a task, or you're not. It doesn't matter *how* you do it. That's why 'listable' or something like it would be a better name for the permission than 'URL Traversable', IMHO (although they both sound *ugly*). Very good points :-) Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Access Control vs Publishing Protoco
Dieter Maurer wrote: Management, however, would be more difficult, as there are no good defaults for the "URL Traversable" permission. It is not easy, to determine (e.g.) for a DTML method/document whether it is only used as a component (such as "standard_html_header") or is a full grown presentation method. The defaults should be as it is now, ie: everything is visible/travesable unless you tell it not to be... cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Access Control vs Publishing Protoco
Dieter Maurer wrote: My primary concern (and maybe Chris') is, how can we prevent these objects to be viewed by Anonymous. Yup, that's exactly my point... cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Access Control vs Publishing Protoco
Seb Bacon writes: OK, I think we're talking about the same thing now...but could you give me an example of any object that would need to be traversable by Anonymous? index_html, for example, doesn't need to be traversable (I still prefer 'listable'). Viewable TTW, yes, but that's all. I do not agree with you: I should be able to list what I am able to view (in order to learn what I can view). I think, more than 30 per cent of my objects are like "index_html". They are designed to be viewed by Anonymous. The others are not destined to be viewed but to be used as components in viewed objects (like "standard_html_*"). The current Zope security requires that Anonymous has view permissions for them, too. But this allows Anonymous to view them in isolation which almost surely will give strange results (exceptions, empty pages, etc.). My primary concern (and maybe Chris') is, how can we prevent these objects to be viewed by Anonymous. If we succeed, then Anonymous can do nothing at all with them and it is no longer necessary to list them (for him). Thus, a solution for this problem may also be a solution for the other problem. However, a "listable" permission would not solve the distinction between directly viewable via the web and only indirectly viewable. Dieter ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Access Control vs Publishing Protoco
oops, I forgot to foward my last mail on this subject to the list. My response here to Dieter's response captures contains the main points though... I think, the implementation would be easy. Management, however, would be more difficult, as there are no good defaults for the "URL Traversable" permission. It is not easy, to determine (e.g.) for a DTML method/document whether it is only used as a component (such as "standard_html_header") or is a full grown presentation method. Um, I don't think I understand. [ snip ] Currently, Zope tries to have very few explicit, object specific permissions. The ideal is that permissions are specified high above in the hierarchy and acquired by lower objects. This is quite possible with the current scheme. Implementing an "URL accessible" permission would require much more tweaking of single object permissions. There are other ways to solve your problem by organization (putting things that should not be seen somewhere else) that do not require an additional permission. Now I understand... I would disagree, however: I think there is a sensible default value. The default would be that anonymous does not have 'traverable' permission, but the manager / owner does. The cases where an authenticated user is able to traverse some objects but not others would, as you point out, be rare, because you could instead manage these by organisation. You would still use organisation to avoid having to set too many additional permissions. However, this solution would solve the 'security' issue of the anonymous user being able to list objectIds in any folder TTW. It would also allow the developer more flexibilty in how they designed their application, which can only be a Good Thing? seb. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Access Control vs Publishing Protoco
This is because the thing which makes
the problem hard is that something like standard_html_header
wants to be
editable by Managers TTW, which means it also has to be visible TTW.
However, it's probably not something you want exposed to anonymous
users, especially as a TTW enitity in its own right. objectIds is my
other favourite example ;-)
OK, I'm still a newbie, and in particular I have yet to get my head round
zope security properly. But I'm going to attempt to comment on this anyway.
For me, the 'visibility' problem is a real bugbear. Apart from the
'security' issue of anon. users being able to list objectIds, it means I am
loathe to allow clients to manage their sites through the manage interface.
This is because they'll see it littered with methods which pop up a login
box whenever they click on them. It looks horrible and unprofessional.
Anyway, I agree with Dieter / Chris. Adding a 'URL Traversable'
('listable'?) permission to all objects and then tweaking methods that do
the traversing (objectIds, objectValues) would presumably fix this? Would
this be easy? I've never had a look at the security internals, but I'm
looking forward to having a go...
Chris W was talking about adding security on a protocol level as well as an
object level, but I can't really see why you would only want to be able to
edit a document through webDAV but *not* TTW. In my mind, you're either
authenticated to do a task, or you're not. It doesn't matter *how* you do
it. That's why 'listable' or something like it would be a better name for
the permission than 'URL Traversable', IMHO (although they both sound
*ugly*). Someone mentioned they found the ftp access permission useful -
I'd be interested to know how / why.
seb.
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Access Control vs Publishing Protoco
Seb Bacon writes:
For me, the 'visibility' problem is a real bugbear. Apart from the
'security' issue of anon. users being able to list objectIds, it means I am
loathe to allow clients to manage their sites through the manage interface.
This is because they'll see it littered with methods which pop up a login
box whenever they click on them. It looks horrible and unprofessional.
I just tried what would happen (as I did not believe it would be
as bad as you described it):
* I gave "Anonymous" the "View Management Screens" permission
for a folder.
* I was then able to access the manage URL for the folder
(without authentication), but the main frame displayed
an acquired "index_html" rather than the folders content
view.
* I tried to manage a containing DTML method, but a login
was requested: "No authentication header".
Apparently, DTML method management requires at least
an authenticated user.
Thus, I played with an authenticated user.
The behaviour was not too bad (though not completely satisfactory).
As you expected, the folder contents displayed all containing
objects, even objects I did not have "View" permissions.
When I clicked on such an object, I got an "manage_workspace" screen
with just the "ownership" tab. Not overwhelming but not too bad either.
When I had "View" permissions but no "change" permissions, I
did not get a "manage_workspace" screen, but the object was
viewed automatically. Not what I would have expected, but not too bad
either.
When I had a "change" permission, I got the expected "manage_workspace"
screen.
Anyway, I agree with Dieter / Chris. Adding a 'URL Traversable'
('listable'?) permission to all objects and then tweaking methods that do
the traversing (objectIds, objectValues) would presumably fix this? Would
this be easy? I've never had a look at the security internals, but I'm
looking forward to having a go...
I think, the implementation would be easy.
Management, however, would be more difficult, as there are no
good defaults for the "URL Traversable" permission.
It is not easy, to determine (e.g.) for a DTML method/document
whether it is only used as a component (such as
"standard_html_header") or is a full grown presentation method.
Dieter
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
