RE: [Zope-dev] Methods through the Web (security?)
How come you can browse things like the objectIds and objectValues methods through the web? Surely this is exposing information that people shouldn't really know about?
You're right - and stop calling me shirley. :) This is something of a holdover from the bobo days - if you are a method and you have a docstring, you are accessible through the web (but still subject to the std security rules). objectIds and objectValues are a good example of things that really only want to be used from DTML and thus shouldn't have docstrings. I've changed this (and a few other iffy methods) for the next release.
While I'm at it, is there any way to make DTML methods accessible to objects (such as other DTML methods) but not through URLs other than by a tortuous series of proxy roles? I've expressed views about an 'execute' permission in the past but these have fallen on deaf ears.
For example: http://www.codecatalog.com/standard_html_footer
This is messy and there's no reason why it needs to be exposed through a URL.
I don't have a good answer for you, though I tend to agree with you that some things just don't want to be accessed outside of some larger context. I'd like to hear some different viewpoints on how people think something like this should work... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
In article <613145F79272D211914B0020AFF640195A719F@gandalf.digicool.com>, Brian Lloyd <Brian@digicool.com> wrote:
How come you can browse things like the objectIds and objectValues methods through the web? Surely this is exposing information that people shouldn't really know about?
You're right - and stop calling me shirley. :) This is something of
Hmm, another ZAZ fan :-)
a holdover from the bobo days - if you are a method and you have a docstring, you are accessible through the web (but still subject to the std security rules). objectIds and objectValues are a good example of things that really only want to be used from DTML and thus shouldn't have docstrings. I've changed this (and a few other iffy methods) for the next release.
Won't this break Amos' XML-RPC-based editor and similar hacks? 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?
Ty Sarna wrote:
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?
"Default security hole" notwithstanding, I would second this. FWIW, being able to type http://blah/objectIds is a pretty darn nice development facility sometimes. -- Chris McDonough Digital Creations Publishers of Zope - http://www.zope.org
Ty Sarna wrote:
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?
Hm, but wouldn't that break a lot of code? You need Access contents information if you're going to do something like automatically generate an index, right? Regards, Martijn
Brian:
While I'm at it, is there any way to make DTML methods accessible to objects (such as other DTML methods) but not through URLs other than by a tortuous series of proxy roles? I've expressed views about an 'execute' permission in the past but these have fallen on deaf ears.
For example: http://www.codecatalog.com/standard_html_footer
This is messy and there's no reason why it needs to be exposed through a URL.
I don't have a good answer for you, though I tend to agree with you that some things just don't want to be accessed outside of some larger context. I'd like to hear some different viewpoints on how people think something like this should work...
I sounds like there's a want for a distinction of things that can and cannot be published(Viewed by URL alone). Do <dtml-var mything> and /mything use different machinery to render the calls? Is there a difference in Zope between 'publishing' and just 'rendering' or calling? If there is (because I haven't looked at any code, I'm just theorizing) they you'd want a permission that allowed processing by either/or both sets rendering and publishing methods. Way-over-my-head-bowing-out-as-I-finish-the-thoughtly yours, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Brian Lloyd wrote:
I don't have a good answer for you, though I tend to agree with you that some things just don't want to be accessed outside of some larger context. I'd like to hear some different viewpoints on how people think something like this should work...
What the difference seems to be is exposure to surfer through URL. So, you could equip all items in the object tree with a flag 'expose', that is off by default. When the user should be able to view the thing through an URL (such as index_html), you turn it on. Would this have any unforseen problems? You could even have some user interface help here. Imagine I made an index_html but forgot to expose it. Now, still logged in as manager, I try to view it. Zope detects I'm trying to view something through an URL that I'm not supposed to see, so asks something like "hey, you tried to view this but it's not set to be exposed, expose this?". If the manager chooses 'yes', the expose flag is set to true. Hm, I suppose the problem here would arise with methods that directly return HTML output through an URL. This would seem to be fairly rare, though, and you can always wrap it up in some object that does have the expose flag. Regards, Martijn
participants (5)
-
Brian Lloyd -
Chris McDonough -
Jason Spisak -
Martijn Faassen -
tsarnaļ¼ endicor.com