Hi, Here's a load of questions that have sprung up as a result of trying to get to grips with SiteAccess 2 on Zope 2.2.1: It looks like REQUEST.steps is the replacement for PARENTS? Is that so? Small grumble: REQUEST['TraversalRequestNameStack'] is a bit of a long-winded name :P
If an Access Rule is broken, and is preventing normal access, it can be disabled by restarting Zope with environment variable SUPPRESS_ACCESSRULE set.
So now you have to restart Zope to undo a screwup? I guess __no_before_traverse__, or whatever it was, was a security whole, or something? Hmm, the example for Multiple Sites isn't very robust :-( http://www.zope.org/Members/4am/SiteAccess2/vhosting You use HTTP_HOST, without ensuring it exists. I remember having problems with this in Zope 2.1.6 as HTTP_HOST doesn't exist when you access things via FTP, so an error gets thrown, effectively preventing you from accessing any objects covered by the access rule through FTP. My solution for this is just to wrap the rule in <dtml-if "REQUEST.has_key('HTTP_HOST')"> Well, that's all for now... cheers, Chris
From: Chris Withers <chrisw@nipltd.com>
It looks like REQUEST.steps is the replacement for PARENTS? Is that so?
Actually, REQUEST.steps has always been there -- it's the list of *ids* that were traversed. This may or may not correspond to the ids of the PARENTS, depending on whether an object with a __bobo_traverse__ inserted extra objects or replaced itself in PARENTS. Then there is REQUEST._steps, which is new, and which is (as the _ implies) for internal use only. It's a pre-url-quoted list of steps, affected by virtual hosting, which is used to construct URLn and BASEn. Right now, I've working in a CVS branch on new REQUEST variables called URLPATHn and BASEPATHn, which are analagous to URLn and BASEn but only contain the path portion of the URL. Then all SCRIPT_NAME uses should be replaced with BASEPATH1, etc.
Small grumble: REQUEST['TraversalRequestNameStack'] is a bit of a long-winded name :P
Agreed. Jim pretty much mandated a name that (1) lives in 'other', rather than being an attribute, and therefore (2) is very, very unlikely to clash with other people's REQUEST variable names.
So now you have to restart Zope to undo a screwup? I guess __no_before_traverse__, or whatever it was, was a security whole, or something?
No, it's just not specific enough. Now that the before-traversal hook is part of Zope, other services may want to use it, and so it shouldn't have a global on/off switch. As of SiteAccess 2.0b3, you can insert "_SUPPRESS_SITEROOT" and/or "_SUPPRESS_ACCESSRULE" into your URL in order to turn off a single SiteAccess object (the one which would have triggered at that point in the URL).
Hmm, the example for Multiple Sites isn't very robust :-( http://www.zope.org/Members/4am/SiteAccess2/vhosting
I didn't spend a whole lot of time fortifying it. It's just meant to be an example, after all. I wasn't expecting so many people to paste it into their applications without understanding what it does. :-) Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
From: Chris Withers <chrisw@nipltd.com>
It looks like REQUEST.steps is the replacement for PARENTS? Is that so?
<snip REQUEST.steps isn't PARENTS replacement> Okay, so given that PARENTS is living in a 'deprecated' list on the Interfaces Wiki, what are we supposed to use instead?!
Agreed. Jim pretty much mandated a name that (1) lives in 'other', rather than being an attribute, and therefore (2) is very, very unlikely to clash with other people's REQUEST variable names.
I know there's gonna be good reason for this, but could someone explain it to me...
"_SUPPRESS_SITEROOT" and/or "_SUPPRESS_ACCESSRULE" into your URL in order to turn off a single SiteAccess object (the one which would have triggered at that point in the URL).
Oooo... is that documented anywhere?
I didn't spend a whole lot of time fortifying it. It's just meant to be an example, after all. I wasn't expecting so many people to paste it into their applications without understanding what it does. :-)
You'd be surprised... ...anyway, I thought you would have remembered given all the fun we had trying to get FTP access to work with SiteAccess ;-) cheers, Chris
participants (2)
-
Chris Withers -
Evan Simpson