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.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -