Re: [Zope] Restricting URL access to objects that are not complete web pages
Steve, Ideally the publishability of an object would be an internal property of that object, not something that is set externally via rules in SiteAccess. It's been a little while since I last looked at SiteAccess, but wouldn't using SiteAccess force you to store publishable objects in one part of the database hierarchy and non-publishables in another? If you wanted publishables and non-publishables all mixed up in the same folders, SiteAccess's rules might get a bit complicated. Another approach could be to: - create a folder that does a RESPONSE.setStatus(404) as the URL traversal machinery passes it. This sets up the default condition of 'NotFound' error for the URL - at the end of the URL, if the final object is publishable or the final item is a publishable method called on a publishable object, do a RESPONSE.setStatus(200) to say 'OK'. Would this be feasible without hacking HTTPResponse.py too much? Stephen ___________________________ Stephen Simmons HealthArena B.V. phone +31 20 486 0555 stephen.simmons@healtharena.net ----- Original Message ----- From: "Steve Alexander" <steve@cat-box.net> To: "Stephen Simmons" <stephen.simmons@healtharena.net> Sent: Thursday, September 21, 2000 3:21 PM Subject: Re: [Zope] Restricting URL access to objects that are not complete web pages
Stephen Simmons wrote:
My thoughts were to use an html_header that tracks how deeply components
are
nested so that inner components turn off the page wrapper. This achieves 1 and 2. This also achieves 3 if sections raise an exception if their page wrapper is not turned off.
You only want to see standard_html_footer and so forth when REQUEST.steps[-1]!=fragment_id, so it would not be accessible directly by URL.
Try something like this for standard_html_footer:
<dtml-if "REQUEST.steps[-1]=='standard_html_footer'"> <dtml-raise type="NotFound"></dtml-raise></dtml-if> </BODY></HTML>
I think using siteaccess for this is more elegant, though. All the knowledge about what is allowed and what is not is maintained in one place, and the knowledge can be declared flexibly using regular expressions.
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Stephen Simmons wrote:
Steve,
Ideally the publishability of an object would be an internal property of that object, not something that is set externally via rules in SiteAccess. It's been a little while since I last looked at SiteAccess, but wouldn't using SiteAccess force you to store publishable objects in one part of the database hierarchy and non-publishables in another? If you wanted publishables and non-publishables all mixed up in the same folders, SiteAccess's rules might get a bit complicated.
Yes, this is not a neat solution, unless you have already designed your site to use siteaccess in this way.
Another approach could be to: - create a folder that does a RESPONSE.setStatus(404) as the URL traversal machinery passes it. This sets up the default condition of 'NotFound' error for the URL - at the end of the URL, if the final object is publishable or the final item is a publishable method called on a publishable object, do a RESPONSE.setStatus(200) to say 'OK'.
Even if you don't reset the status to 200 and it remains as 404, the page will still get sent to the browser. You don't want to mess with the traversal machinery on this, as you want traversal to continue to work as it does now. I think your intent is to block direct requests from a web-browser for particular objects. The easiest way of doing this is to check REQUEST.steps[-1] to see if it equals the current object's id. If you want this to be fairly transparent, perhaps based on a particular permission or property, then I think you'll need to patch part of Zope, probably HTTPRequest.py. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
If you want this to be fairly transparent, perhaps based on a particular permission or property, then I think you'll need to patch part of Zope, probably HTTPRequest.py.
This is the basis of what my proposal on dev.zope.org was about. This could then be extended so you have one permission/property per protocol (HTTP/FTP/DAV/etc) It would make things neater and probably more secure, but sadly no-oen really seemed interested :-( If anyone does do any patchign for this, please let the list knwo and stick it in the collector for good measure, as well... cheers, Chris
participants (3)
-
Chris Withers -
Stephen Simmons -
Steve Alexander