Chris Withers writes:
Toby Dickenson wrote:
Those people were concerned that too many things were exposed via ZPublisher also.... My interpretation was that the issue is one of access control, not publishing protocol.
I think the issue is that you can't limit the visibility of objects right now. .... but there doesn't appear to be any easy way to say "right, I want this object exposed for reading and writing via FTP and reading via HTTP, while this one shouldn't be URL traversable but I'd like to edit it via WebDAV and this method is for use via XML-RPC but really shouldn't be visible anywhere else.) I agree with Toby:
Unless there are drastic differences in capabilities for protocols, we should focus on access/visibility independent of protocol. To get a feeling what I mean with drastic differences: When SOAP access would allow me to "attack" (hack, espionage, steal, or whatever) a Zope site in some minutes when the same attack would take years via HTTP, then we should be concerned with protocol specific forms of restrictions. However, as Toby pointed out, up to now I can do as bad things via HTTP as I can do with any other protocols.
.... 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 ;-) I think, this could be easily achieved:
* provide a "version" of "objectIds" that filters according to authorization. It would return the list of id's for objects I am allowed to see. * This would not yet cover the case of "standard_html_header" and other presentation "components" (that should not generally be seen as independent entities). To handle this case, a different permission would be necessary to distinguish between TTW use and use from inside the presentation machinery (DTML, Templates, whatever). An "URL traversable" permission, as suggested by Chris, seems to fit the bill. Dieter
.... 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.
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
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
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
participants (3)
-
Chris Withers -
Dieter Maurer -
Seb Bacon