<br><br><div class="gmail_quote">On Tue, Mar 25, 2008 at 9:19 AM, Jim Fulton <<a href="mailto:jim@zope.com">jim@zope.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Mar 25, 2008, at 5:25 AM, Martijn Faassen wrote:<br><br>
> Security proxies: this topic may not be directly publisher related,<br>
<br>
It's not.<br>
<br>
> but maybe it is.<br>
<br>
Nope. :)<br>
<br>
> Somewhere quite low in the request handling of Zope 3 a security<br>
> proxy is introduced around the objects being traversed.<br>
<br>
This is done by the default Zope 3 publication object,<br>
zope.app.publication.zopepublication.ZopePublication.</blockquote><div><br class="webkit-block-placeholder"></div><div>i've deployed apps with a custom zopepublication in part to bypass security proxies, and its unfortunately not the only place that injects security proxies. the more difficult injection point to avoid is the one in</div>
<div> </div><div>zope/app/pagetemplate/engine.zopeTraverser<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
> Grok doesn't want security proxies, so rips them off again in a<br>
> custom publisher. It'd be nice if there were a hook point that would<br>
> enable us not introducing this proxy in the first place.<br>
<br>
<br>
There always has been, as I've mentioned many times. The same hook<br>
point allows use of Zope 3 without ZODB. These policies are provided<br>
by the publication object. It's a shame that the convoluted setup<br>
system made this so inaccessible.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
My hope is that zope.publisher.paste makes it *much* easier to use a<br>
different publications and thus a different set of policies. (I plan<br>
to update zc.zope3recipes to provide an instance recipe pased on paste.)<br>
<br>
I'm 99% sure that most or all of the simplicity to want has already<br>
been there for a long time or is there now with the simpler setup<br>
framework in zope.publisher.paste.</blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Note that my proposal wasn't to simplify the publisher. I think it<br>
already is pretty simple and I hope the recent zope.publisher.paste<br>
work exposes the simplicity by stripping off layers of overly complex<br>
setup. My proposal was simply to extract some core functionality in a<br>
way that greatly reduces dependencies. I don't expect this stripped<br>
down version to be of interest to most of the zope community. I do<br>
think it might be useful to people with much more limited needs. I<br>
didn't the proposal because I thought it would be of general interest,<br>
but to ask permission. I want to do this refactoring, to avoid a (yet<br>
another) fork of the publisher. I should have made this clearer.<br></blockquote><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><div>this all sounds really nice. i've been doing rdb apps with zope with custom publications.. but getting the initial setup right for wsgi involved some dead chickens to reimplementing the the wsgi application setup that had zodb bits setup and event firing hardcoded.</div>
<div><br class="webkit-block-placeholder"></div><div>looking over the new zope.publisher.paste code, it looks like it also pushes the responsibility for application setup to the publication factory.. ie. zcml loading, application startup events.</div>
<div><br class="webkit-block-placeholder"></div><div>+1 </div><div><br class="webkit-block-placeholder"></div><div>cheers,</div><div><br class="webkit-block-placeholder"></div><div>kapil</div></div></div>