Re: [Zope-dev] Methods through the Web (security?)
Chris Withers <chrisw@nipltd.com> opined:
Brian Lloyd wrote:
[snip]
Won't this break Amos' XML-RPC-based editor and similar hacks?
Waaa.... probably. Ok, so I've _provisionally_ changed this in the current CVS. I feel a to-the-death-cage-match coming on.
Horse before the cart?
Maybe the XML-RPC editor needs fixing 'cos something got fixed in Zope?!
Can't you just turn off 'Access contents information' permission or whatever it is on a folder if you don't want people to call those things trough the web?
Yes you could, except that you would also make them inaccessible from DTML (or from anywhere else) for the same class of users.
...as I found out when I first ran into this problem...
...and as I said in the first post you can get round this using a tortuous set of proxy roles (dunno how that'll get screwed up in 2.2) but it's not a 'nice' solution to what should be a fairly simple problem.
Is it really acceptable that in order to use <dtml-in objectIds> on a page that needs to be accessible to anonymous users that I must grant 'Access contents information' to anonymous users and thus give them the ability to inspect my objects if they want to?
No!!! ;-)
I don't get the issue here, I guess; either anonymous users can view objectIds (through the web, through XML-RPC, whatever), or they can't (because you don't want them to have the information that a given object is there, I guess?) If they can't, then _any_ DTML method which calls objectIds() should be required to have non-anonymous permissions, either through the AUTHENTICATED_USER or through proxy roles. This seems to be working as designed in the current implementation. Turning off objectIds() by default is like running an anonymous FTP server but disallowing the "dir" command: it reduces the utility of the server to such an extent that you might as well not bother. :) An alternate implementation would be to have objectIds() check for the anonymous role, and return only the subset of IDs that the 'skip-unauthorized' attribute filters in <dtml-in> (this touches on another peeve of mine -- lots of the "magic" which DTML does is not accessible outside of the tags).
The solution I proposed before is simple (maybe not to implement ;-) and I think solves all the problems:
Split the current 'view' permission into two new permissions:
1. View - allow users to directly access an object through HTTP/FTP/XML-RPC/etc
2. Execute - allow non-direct execution of a method by a user, for example by them viewing another method/object which they have the 'view' permission for.
This effectively provides the same functionality as adding or removing a docstring from a method in a python class, and could be used to replace it, as it's not really documented anywhere.
I can't really see a use for he 'Access contents information' permission other than an additional control over and above these two new ones.
As simple example: -index_html (role X has view permission) <dtml-var standard_html_header> Some Text </BODY></HTML>
-standard_html_header (role X has execute but not view permission) <HTML><BODY>
So, a user with role X can view index_html and have it render properly (although it wouldn't if he didn't have the execute permission on standard_html_header) but if the user tried to view standard_html_header on its own, he would get an unauthorised error...
Comments? (hopefully I'll get some this time... ;-)
cheers,
Chris
PS: The XML-RPC stuff could just be given the nwe view permission for objectIds, if it REALLY needs it... although this would mean the docstrings thing would have to eb replaced, which isn't necessarily a bad thing ;-)
Itamar Shtull-Trauring <itamar@maxnm.com> replied:
Yes, it really needs it. My XML-RPC uploading interface to Zope needs to know what's in a folder - so it needs objectIds. How else am I supposed to browse through the Zope tree? I could have users install a method, but this is a very generic need (browsing the object tree) and should be built in.
Steve Alexander <steve@cat-box.net> chimed it:
It occurs to me that there are two distinct "views" of the Zope tree.
1. The developer's / content manager's view
This is what we have now.
2. The end-user's view
Taking HTTP as an example, this consists of the set of URLs that are available for access via the web. Other URLs should return a 404 Not Found, even if they are available as part of the developer's view (point 1).
Taking HTTP alone, for simplicity of expression; I suppose what I'm asking for is that there are two HTTP servers for one Zope instance. The one on port 80 (for example) only responds to those URLs that are for public viewing. The one on port 8081 (for example) responds to any request that makes sense to map onto an object or attribute.
The same scheme can be applied to FTP -- you choose whether a particular FTP server presents the "public" view, or the "developer" view.
I'm presuming you mean to disallow anonymous access to the "developer" view -- otherwise, you have just transferred the "security-through-obscurity" to another location. Providing dual HTTP servers is actually useful in another way -- it allows you to both develop and test from within the same browser session, without sharing credentials. Patches accepted :) (hint: look at how z2.py initializes the HTTP server). Tres. -- ========================================================= Tres Seaver tseaver@digicool.com Digital Creations "Makers of Zope" http://www.zope.org
Tres Seaver wrote:
Taking HTTP alone, for simplicity of expression; I suppose what I'm asking for is that there are two HTTP servers for one Zope instance. The one on port 80 (for example) only responds to those URLs that are for public viewing. The one on port 8081 (for example) responds to any request that makes sense to map onto an object or attribute.
The same scheme can be applied to FTP -- you choose whether a particular FTP server presents the "public" view, or the "developer" view.
I'm presuming you mean to disallow anonymous access to the "developer" view -- otherwise, you have just transferred the "security-through-obscurity" to another location.
You could. I'd like to do this so that I could block port 8081 (in the example above) at my firewall, or apache config, or whatever. In that way, I get a "neat and tidy" public-viewable website, and a developer site that is viewable only within my network's DMZ. -- Steve Alexander Software Engineer Cat-Box limited
Tres Seaver wrote:
I don't get the issue here, I guess; either anonymous users can view objectIds (through the web, through XML-RPC, whatever), or they can't (because you don't want them to have the information that a given object is there, I guess?)
Perhaps you just don't want to expose internal implementation details to them. Users have no business viewing 'standard_html_header' directly, for instance.
If they can't, then _any_ DTML method which calls objectIds() should be required to have non-anonymous permissions, either through the AUTHENTICATED_USER or through proxy roles. This seems to be working as designed in the current implementation. Turning off objectIds() by default is like running an anonymous FTP server but disallowing the "dir" command: it reduces the utility of the server to such an extent that you might as well not bother. :)
I think this picture changes if you make the distinction between viewing as an anonymous user, viewing as the manager, viewing through XML-RPC, etc. I think the idea is that a random person on the web should only be able to view that which that user is explicitly allowed to view. Preferably the user should not have the capability to access things directly that are actually only DTML/Python methods used to *produce* the view. If you could say to a method that it is like that, you can make a distinction that can currently not be made. i.e. a 'viewable through URL' permission (default set to off). Regards, Martijn
participants (3)
-
Martijn Faassen -
Steve Alexander -
Tres Seaver