Re: [Zope-CMF] Security declarations on adapters
On 6 September 2012 14:06, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 06.09.2012, 13:11 Uhr, schrieb yuppie y.2...@wcm-solutions.de: Good. What is, in your view, missing from a final release? Laurence proposed some changes for the utilities: https://mail.zope.org/pipermail/zope-cmf/2012-September/030381.html If we agree that's the way to go, I'd like to have his changes in CMF 2.3 before the final release. Unless something downstream is dependent on these kind of changes I don't see any reason to including them at this late stage. I think the downsides from leaving it out are: * Another branch of five.localsitemanager to maintain. * Incompatibility between CMF 2.3 and Zope 4 once the parent pointer changes go in. Plone is unlikely to make a CMF upgrade until it removes its CMFDefault dependency. Laurence The main downside to leaving the changes out is the necessity of another five.localsitemanager branch to maintain. The changes are compatible with CMF 2.2, but it may not play nicely with the ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On 5 September 2012 11:48, yuppie y.2...@wcm-solutions.de wrote: 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. getToolByName is no option because it is part of the machinery that should become obsolete. getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient. But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root. How about introducing a new getPortal() function? It could simply use getSite() then walk back down the acquisition chain until finding an object that directlyProvides ISiteRoot. In Plone KSS can introduce another 'component site' between its view and the portal itself. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On 5 September 2012 13:26, yuppie y.2...@wcm-solutions.de wrote: Hi Laurence! Laurence Rowe wrote: On 5 September 2012 11:48, yuppie y.2012-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. getToolByName is no option because it is part of the machinery that should become obsolete. getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient. But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root. How about introducing a new getPortal() function? It could simply use getSite() then walk back down the acquisition chain until finding an object that directlyProvides ISiteRoot. In Plone KSS can introduce another 'component site' between its view and the portal itself. Not sure why the discussion takes this direction. My point was that several CMF tools/utilities might not work correctly if the site root is not their parent. The difficult part is not to look up the site root. The difficult part is to figure out where a lookup is required. I don't think relying on getSite() is a good idea. As you mention it doesn't always return the portal object. And the fact it is stored with the request in its context is just an accidental side effect. What would be the advantage compared to using getUtility(ISiteRoot)? While it's an accidental side effect, it is something we could make use of. Once I merge my parent pointers branch into Zope 4 (hopefully soon), RequestContainer wrapping is completely removed and all objects with __parent__ pointers to the Application root will always have their correct context (and be able to acquire the REQUEST.) This will allow getUtility(ISiteRoot) to function correctly, along with any other tools/utilities that have their __parent__ pointer set. The branch lives on a temporary repository at https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I expect some problems with CMF trunk following the removal of RequestContainer, but I hope to address these once I get it merged. I'll try and post a proper writeup of its state and how to make it run in the next few days. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On 5 September 2012 15:36, yuppie y.2...@wcm-solutions.de wrote: Hi! Laurence Rowe wrote: On 5 September 2012 13:26, yuppie y.2012-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: I don't think relying on getSite() is a good idea. As you mention it doesn't always return the portal object. And the fact it is stored with the request in its context is just an accidental side effect. What would be the advantage compared to using getUtility(ISiteRoot)? While it's an accidental side effect, it is something we could make use of. Once I merge my parent pointers branch into Zope 4 (hopefully soon), RequestContainer wrapping is completely removed and all objects with __parent__ pointers to the Application root will always have their correct context (and be able to acquire the REQUEST.) This will allow getUtility(ISiteRoot) to function correctly, along with any other tools/utilities that have their __parent__ pointer set. The branch lives on a temporary repository at https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I expect some problems with CMF trunk following the removal of RequestContainer, but I hope to address these once I get it merged. I'll try and post a proper writeup of its state and how to make it run in the next few days. Great! Making the REQUEST attribute of the app object a shortcut for using globalrequest looks like a good BBB solution. But - this is still a Zope 2 (Zope 4) specific feature. I hope you don't plan to recommend using it in new code. A PendingDeprecationWarning might be useful to figure out which code is using that legacy feature. - that doesn't explain why you propose using getSite() instead of getUtility(ISiteRoot). - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4 features. Precisely because CMF 2.3 targets Zope 2.13 - persistent local utilities returned by getUtility lack any sort of acquisition context in Zope2, so the result of getUtility(ISiteRoot) will return aq_base(portal), which is unlikely to be useful. getSite() instead returns the component site set as a thread local during traversal. Assuming that has an acquisition context including the portal then we have the portal object with its correct acquisition context so can call portal.absolute_url(). Another alternative would be to set the portal directly as a thread local during the traversal (just as setSite() is called) and clear it at the end of the request. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On 5 September 2012 17:15, yuppie y.2...@wcm-solutions.de wrote: Laurence Rowe wrote: Maybe I'm missing something, but the various methods of IURLTool rely on portal.getPhysicalPath() returning the correct result. Take getRelativeContentPath for example: portal is at /folder/portal content is at /folder/portal/content getUtility(IURLTool).getPortalObject().getPhysicalPath() will be ['portal'] getUtility(IURLTool).getRelativeContentPath(content) will be ['porta', 'content'] instead of ['content'] You'd need to stop having any portals contained in folders, something that's fine for new sites but will prevent upgrades. Not sure who is missing something and what. Just a wild guess: Are you aware of the fact that five.localsitemanager just removes the RequestContainer, not the complete acquisition chain? And that CMF 2.3 adds a RequestContainer in getPortalObject()? Ok, I wasn't aware that five.localsitemanager restored a partial aq chain. The RequestContainer is removed to avoid caching old requests as part of the aq_chain of utilities. Instead of removing the RequestContainer, it could be replaced with a zope.globalrequest aware RequestContainer. That might be cleaner than rewrapping in individual utilities, and would work with Zope 2.13. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-dev] makeClass and makeClassForTemplate
Hi Yuppie, Now that you've cleaned up Products.Five in Zope trunk, what should other packages that use ``makeClass`` and ``makeClassForTemplate`` change to? For five.formlib I simply exchanged ``makeClass`` for ``type`` and ``makeClassForTemplate`` for ``SimpleViewClass``, see: http://zope3.pov.lt/trac/changeset/127697/five.formlib/branches/zope-trunk-compat Would these changes be ok for packages that want to continue working with Zope 2.13? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] makeClass and makeClassForTemplate
On 4 September 2012 22:23, yuppie y.2...@wcm-solutions.de wrote: Hi Laurence! Laurence Rowe wrote: Now that you've cleaned up Products.Five in Zope trunk, what should other packages that use ``makeClass`` and ``makeClassForTemplate`` change to? Well. I wasn't aware of the fact that other packages use these constructors. Please let me know if you think additional BBB support is needed. For five.formlib I simply exchanged ``makeClass`` for ``type`` and ``makeClassForTemplate`` for ``SimpleViewClass``, see: http://zope3.pov.lt/trac/changeset/127697/five.formlib/branches/zope-trunk-compat Would these changes be ok for packages that want to continue working with Zope 2.13? AFAICS it's fine to use the ``type`` constructor instead of ``makeClass`` in Zope 2.13. ``SimpleViewClass`` is not available in Zope 2.13, so that part will not work in Zope 2.13. ``makeClassForTemplate`` has a slightly different signature, but the way five.formlib uses it should work with both versions. So I would fall back to ``makeClassForTemplate`` if import of ``SimpleViewClass`` doesn't work. Other than five.formlib, I only found makeClass being used in plone.app.portlets and kss.core. I've fixed both of those to use type instead and have used the suggested fallback for five.formlib on trunk. I don't think we need any BBB support in Zope itself for this. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Restoring zLOG trunk
On 30 August 2012 15:56, Laurence Rowe l...@lrowe.co.uk wrote: On 29 August 2012 15:44, Tres Seaver tsea...@palladion.com wrote: On 08/29/2012 09:25 AM, Tres Seaver wrote: That base class has been gone since ZConfig 2.9.2. I don't think the Zope2 trunk has pinned / unpinned ZConfig in a long time, so I'm not sure why it would just now break (ZConfig 2.9.2 was released in February, and 2.9.3 in June). I just pushed a change to the Zope2 trunk to use the new speling. While Tres fixed the error on Zope trunk, the same fix is still needed by zLOG. According to http://svn.zope.org/repos/main/zLOG/README-trunk.txt: This package has been re-integrated into the Zope2 package. Maintenance happens on the 2.11 branch and new development could occur inside `Zope2/src/zLOG`. However, Zope 2.12, 2.13 and trunk still use the egg and the only place it seems to exist in that package is at /Zope/branches/2.11/lib/python/zLOG, presumably where it was moved from during eggification. I'm going to restore zLOG trunk by copying in the current 2.11 branch so it can be fixed in a similar manner. zLOG 2.12.0 released and Zope trunk versions.cfg updated to use it. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Python scripts
On 6 July 2012 14:09, Richard Harley rich...@scholarpack.com wrote:
On Zope 2.10 is there a simple/universal way to only allow python scripts to
be called by DTML methods or other python scripts and not directly TTW?
You can check that the script is not the published object with:
if container.REQUEST['PUBLISHED'] is script:
raise 'Forbidden'
For newer versions of Zope raise an exception object:
from zExceptions import Forbidden
if container.REQUEST['PUBLISHED'] is script:
raise Forbidden('Script may not be published.')
Laurence
___
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Python scripts
On 6 July 2012 16:36, Richard Harley rich...@scholarpack.com wrote:
That works great, thanks. So there is no way to do this across, say, a
folder with hundreds of scripts in without duplicating the code in each
individually?
For one Plone hotfix we took the approach of blacklisting certain
scripts by monkey-patching Bindings._bindAndExec (Bindings is a
superclass of PythonScript):
from Shared.DC.Scripts.Bindings import Bindings
from zExceptions import Forbidden
DO_NOT_PUBLISH = [
'script_id',
...
]
def _patched_bindAndExec(self, args, kw, caller_namespace):
'''Prepares the bound information and calls _exec(), possibly
with a namespace.
'''
template_id = hasattr(self, 'getId') and self.getId() or ''
request = getattr(self, 'REQUEST', None)
if (template_id and request and template_id in DO_NOT_PUBLISH and
request.get('PUBLISHED') is self):
raise Forbidden('Script may not be published.')
return self._original_bindAndExec(args, kw, caller_namespace)
Bindings._original_bindAndExec = Bindings._bindAndExec
Bindings._bindAndExec = _patched_bindAndExec
You could create an unpublishable subclass of PythonScript using a
similar technique. Ideally PythonScripts would opt in to being
publishable based on some metadata option.
Laurence
___
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] [ZODB-Dev] RFC: release persistent as a standalone package
On 1 July 2012 02:16, Leonardo Rochael Almeida leoroch...@gmail.com wrote: I'm +1 on the change even without the answer to my next question, but can you elaborate on what is the advantage of releasing persistent appart from ZODB? As well as the clearer separation of concerns it opens up the possibility for other persistence systems to adopt persistent for detecting changes to mapped objects, gaining the benefit of its fast C implementation. The BTrees package is also useful outside the context of the ZODB. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Sessioning
On 23 May 2012 10:56, Richard Harley rich...@scholarpack.com wrote: Does anyone have a recommendation on how to implement sessioning on Zope 2? Basically to set browser timeouts for the user so logout after say 20 mins of inactivity. The difficulty we've had previously is detecting what exactly 'inactivity' is... Cheers Rich Take a look at http://pypi.python.org/pypi/plone.session It's a PAS plugin that uses signed cookies rather than server side sessions. These cookies are timestamped and have an expiration timeout after which they are considered invalid. When you use a short timeout then there is some javascript that will update the cookie periodically while the user is active on the page. Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] enhancements to RAM cache manager product
On 9 February 2012 05:42, sathya pyt...@zeomega.com wrote: Greetings, ram cached pages using the ram cache manager product seems to be a nice way to improve response times. As far as I remember it did not work well with ZEO. Is there any merit to reengineering this product to use memcached as the backend instead of ZODB/ZEO ? If so would anyone have an interest to work on this as a funded project ? It will be great to hear about newer and better solutions as well. Did you try http://pypi.python.org/pypi/Products.MemcachedManager ? Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Zope 4 release management
On 1 February 2012 14:35, Jonathan Ballet j...@multani.info wrote: On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote: What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) Just to be sure I keep the fire on: what about self-hosted Gitorious? It's not as neat as Github, but you still have the same (similar) forking/merging abilities than Github. From me, the key advantage of Github is the functionality to easily discuss code in pull requests and the one-click merging where appropriate. It takes me much less effort to respond to a Github pull request where I have all the relevant information to hand than an email with a patch or a request to take a look at a branch in subversion. For projects I work on in my own time that often makes the difference when it comes to responding in a timely manner. Github certainly has it's problems too, but it has an api for scripting which makes it possible to send better commit emails or integrate with Launchpad for bug tracking if someone wants to put the effort in. I don't really have an opinion on whether Github or a repository hosted on a zope.org server is nominated as the ZF's canonical repository (presumably with a pre-receive hook that checks all commit authors are known to have signed the contributor agreement.) With DVCS it shouldn't really matter. It's access to improved tools that's important for me. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 ZMI sprint report
On 26 January 2012 04:29, Christopher Lozinski lozin...@freerecruiting.com wrote: Thank you for the sprint report. I think it is great that you are working on upgrading the ZMI. I am also turning my attention to this problem. Clearly ZMI needs an upgrade. I need an upgraded ZMI. Today I fired up my old version of ZAM. I can give you a password and url if you want to see what it looks like. My understanding is that it is a well thought out upgrade for the ZMI. Properly done with page templates, not dtml, and pluggable. It certainly looks nice. Of course it has copy, cut, delete, rename, but no create. I also did a reinstall of the ZAM demo, but it broke. Am I doing the wrong thing working on ZAM? Is that consistent with the direction others are taking on upgrading the ZMI, or should I be putting my energy elsewhere? If I am doing the right thing working on ZAM, perhaps the first thing I should do is get the install working again correctly. For that I have to get svn access from the Zope foundation. I presume Larry Rowe is the release manager for Zope 4, so he is the person who signs off on the upgrades to ZAM? Do I understand the process correctly? Is ZAM part of Zope 4? Is it the basis of the new ZMI, or is something else the new ZMI? I think building a better ZMI will be important in the long run though I'm not sure it should land in Zope 4 itself as I think it could be too big a step for that release. I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. I can volunteer some time towards guiding the Zope 4 release process, though it may be appropriate to find someone more comfortable with the existing svn/email/launchpad toolchain to be release manager if the consensus is to stay with that. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WSGI investigation
On 3 January 2012 08:34, Sylvain Viollon sylv...@infrae.com wrote: Op 1 jan 2012, om 20:39 heeft Martin Aspeli het volgende geschreven: Hi, Hello, There are three known WSGI implementations of the Zope 2 publisher. I've had a look at them and made some notes about what I think provides the best story: ## Zope 2.13 WSGIPublisher [...] ## infrae.wsgi Pros: * Clean and well documented * Properly emits publication events * Supports streaming Those two points are features I use actively in Silva, and where motivation for me to work on my implementation. (I had a look before to repoze.zope2 and the default Zope 2 support, back in 2.12). * Supports simplified virtual hosting with X-VHM-Host That is not completely true. I support setting the hostname, however to set a virtual path, you need to do this during traversing, which is done in BaseRequest, that I don't change (because it is a big large blob of code where you cannot really plug anything in it, or change only a few line in it without changing everything). In production we use mod_rewrite to rewrite the URL with an old VirtualHostMonster url and pass it to mod_wsgi with the help of the flags PT. What advantage is there to setting the X-VHM-Host header over just setting the Host header? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Supporting interworking with repository branches on github
On 24 November 2011 07:58, Wichert Akkerman wich...@wiggy.net wrote: On 11/24/2011 01:29 AM, Florian Friesdorf wrote: On Wed, 23 Nov 2011 09:50:49 -0500, Tres Seavertsea...@palladion.com wrote: Second, it is already feasible to work with modern VCSes against the existing SVN repository: I've been doing it with bzr for literally years now; I know of lots of documentation on using git against SVN as well. Of course, Github is more than a VCS, but its main advantage over other solutions lies in being able to accept casual contributions from non-core developers, which is hardly in scope for the early phases of the Zope4 effort. github enables a peer review process: while everybody who signed the plone committer agreement could just commit to the plone repo, we do pull-requests and somebody else with commit rights checks the request and merges. We've never had a problem with peer review before. People review the commit lists which receive all commits with full diffs and react if they see something off. That is a very well working peer review system. I don't see that improving with github; in fact I see it becoming worse: commit emails no longer get diffs at all, and people are less likely to look at a webinterface for a quick review than they are to take a quick look at an email. The move from Plone to github certainly made me stop all review work, where I reviewed all commits to core code before. I'm not sure I agree with that, it's certainly been an issue in CMF for instance. Where we really miss out is that only a fairly small group of people feel confident enough to commit their changes, and as a group we do a poor job of encouraging new contributors as patches are often left in the bug tracker. I certainly find it much easier to review a pull request and click merge from the github interface (leaving it to Jenkins to validate that the tests continue to pass.) For the long term health of the project this is vital, we're not replacing the developers we're losing. It certainly shouldn't be that difficult to produce our own emails with full changesets for Plone, it just requires someone who misses them to pick it up. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Supporting interworking with repository branches on github
On 23 November 2011 06:58, Wolfgang Schnerring w...@gocept.com wrote: * Tres Seaver tsea...@palladion.com [2011-11-22 22:46]: On 11/22/2011 12:13 PM, Laurence Rowe wrote: While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. Please don't try to jump the gun on the process here [...] It is not appropriate for a small subset of the community to preempt this kind of choid: ask forgiveness rather than permission is *not* going to fly here, and trying to push harder only irritates folks you might otherwise persuade. When reading the emails on this list about this topic, I get a strong feeling of us vs. them. Is that really necessary? In that light, and trying to make visible the (positive!) aspects of the different opinions, allow me to ask: Tres, while I realize that you also rightly raise the formal issue that a vocal minority shouldn't surge ahead and create facts, do I understand you correctly that the main inherent[1] issue is a legal one, concerning proper handling of copyright etc.? Could someone explain what's at stake here, since at least I only have a vague feeling of if something in that area goes wrong, it could be really bad? Laurence, do I understand you correctly that your main concern is ease of use for development and that decentralized version control would be preferable to a centralized one? Do you feel unduly blocked by the need to resolve these (rather tricky) legal issues? Might a technical solution be of use until this is resolved (git can read/write svn, can't it)? Yes, we want to benefit from the ease of merging afforded by git and be able to use the excellent facilities that github provides. Unfortunately git-svn is really only a tool for an individual developer (collaboration still takes place in svn) and does not bring the benefits that a real git repository does - the ability to collaborate on github and use the tools provided there. The current scratch repository is a conversion using svn2git, as that has proper support for tags. It's not clear to me what the blocking issues are from the ZF perspective, whether legal or just that most ZF members don't want to use git. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 roadmap
On 22 November 2011 10:13, Sylvain Viollon sylv...@infrae.com wrote: Op 17 nov 2011, om 20:57 heeft Tres Seaver het volgende geschreven: Hello, On 11/17/2011 02:05 PM, Laurence Rowe wrote: On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: snip - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Note that there is a counter-trend here among the Pyramid crew: many developers *want* tight integration of authentication, particularly the login forms. And there is a major issue with this is that for the moment your authentication depends from where you are in your Zope 2 application. Maybe in some part of the application the authentication will be done using LDAP, and not in some other: you can have a acl_users only for some part of the application, and users there are available locally and not globally. That is because the authentication is done after the traversing. If you want to do this in a WSGI middleware, you will have to do the traversing in a WSGI middleware before, otherwise lot of people won't be able to migrate theirs applications to Zope 4, because the paradigm changed. I don't think this is a good idea because of that. Do you have multiple acl_users folders in a single Silva site? Or is it simply the same case as Plone where you might have multiple sites within the one ZODB? In the long run I expect that Plone will move to configuring multiple sites in a single instance through the WSGI configuration (rather than by creating sites through the ZMI.) In this scenario it would be possible to have different authentication configurations for each site in the WSGI config. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Supporting interworking with repository branches on github
As you are already aware, at the SF Zope sprint we used Git and github for our work. The work contained in https://github.com/zopefoundation is by people who have already signed the Zope Foundation contributor agreement. While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. We want to do this in a way that maintains flexibility for code committed to Git to also be committed to svn.zope.org, so it would be helpful to get a list of Name, Email, username for svn.zope.org committers to facilitate the creation of an author mapping file. (Presumably this information is in LDAP or similar.) We would of course be happy to hand administration rights of the github organization to the Zope Foundation if it was felt to be helpful in ensuring that contributions to that repository counted under the committer agreement. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 release management
Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. Development Process --- We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) I don't have any opinion on where the canonical repository should be hosted - I know some people have strong opinions that this should be on Zope Foundation controlled hardware. If that's to be the case then we will need the svn.zope.org maintainers to setup a shared git repository on that machine. I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 4 roadmap
Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS - Remove XML zexp export (davisagli). - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. - Decorators for AccessControl (chaoflow). Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. - Unicode IDs in OFS - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item - New ZMI - Move authentication out to WSGI middleware. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from the wider ZTK community as the ZTK components will need - Move to Python 3. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 16:32, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 07:25 AM, Laurence Rowe wrote: Along with David Glick, I would like to volunteer for the Zope 4 release management role, where I would take responsibility for producing the initial release of Zope 4 and David would then take over for the maintenance releases. In doing so, I thought it would be helpful to set out our understanding of the mission of Zope 4. If accepted I'll work to produce a first draft of a roadmap based on the outcome of the recent sprints and discussions on this mailing list. Mission --- Zope 4 will be the first of several releases that seek to simplify our software stack. Over the years Zope 2 grew through the adoption of new technologies, notably Zope 3, but rarely removed older ways of doing things. Below, 'Zope 4' refers to the series of releases including Zope 5, 6, etc. Over the series of releases, Zope 4 will progressively remove more and more software as we transition to using software components shared with other Python web frameworks. It is as important to state what Zope 4 *is not* as what it should be: * Zope 4 will not seek to be of interest to those developing new applications. They should instead look to projects such as Pyramid that build on the experience and technologies of Zope without regard for the backwards compatibility concerns that will constrain Zope 4. * Zope 4 will not seek to innovate in itself but encourage innovation in software components shared with the wider Python web community. I smell something funny in here: if we aren't innovating, why are we making the effort? Zope 3, Grok and Pyramid have all innovated already. This is about making better use of those existing innovations and progressively removing code and dependencies from what is currently Zope2. * Zope 4 will not move so quickly that it becomes impossible to make Plone, its main consumer, work with it. We should be working to enable the other Zope2-consuming projects to keep up, too. I see Zope 4,5... very much as a transition path. I expect the different Zope2 based projects will move down that path at different speeds and that Plone will drive it by virtue of its larger developer base. Most of the other Zope2 based applications do not have the same wide community of developers to draw on. * But neither will Zope 4 seek to retain backwards compatibility at any cost. As the basis of Plone 4, Zope 2.13 will see maintenance releases as long as Plone 4 is supported. As long as any significant body of developers commits to maintaining it, even if the Plone devs don't care any more. Of course. I expect that for some existing Zope2 applications that will be the easier path. * Zope 4 will not have a release cycle independent of Plone. Zope 4 only exists as a transitional path for Zope 2 based applications and experience has shown that Zope 2 releases not used in any Plone release do not receive the same level of ongoing maintenance. I would actually argue that Zope4 have no real release cycle at all: instead, the individual pieces which make up Zope should have their own cycles, with perhaps a ZTK-like tracking set that Plone and others use as platform targets. At some point we will need to make a release that will receive bug fixes. The best point to do that will be the same time as a Plone release. This probably applies more to the central distribution (currently named Zope2), the other subsidiary distributions will certainly go their own way (as we've already seen with DateTime, ZPublisher, etc.), though any included with a Plone release will have a much larger number of people invested in making future bug fix releases. We want to encourage all features to be developed on separate feature branches so we can maintain a stable trunk. Before these feature branches are merged they should be posted to the mailing list for review. This process will necessitate a lot of merging, so I want to propose that we move to Git for development (something we found very helpful at our recent San Francisco Zope 4 sprint.) Note that this question is *not* suitable for loudest voice on zope-dev wins ressolution. The software belongs to the Zope Foundation, which will make any such decision. The work done on github by the Zope4 sprinters in SF should be seen as scratchpads for work which will be migrated back into the canonical repository for each project. The current repository on Github is indeed a scratchpad. We would want to do a better job of migrating usernames for a final migration (we would need an svn username - name and email address map.) A couple of points for consideration: - - bzr and hg are pretty much isomorphic to git WRT this kind of practice. Both have claims on our community which Git does not (hg because it is the tool of choice for Python, bzr because we already
Re: [Zope-dev] Zope 4 roadmap
On 17 November 2011 15:23, Martin Aspeli optilude+li...@gmail.com wrote: On 17 November 2011 14:46, Laurence Rowe l...@lrowe.co.uk wrote: Here's my current understanding of the Zope 4 roadmap. Zope 4 -- Significant progress has already been made on the following features and I expect they should all land in time for a Zope 4 release: - Storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers on objects implementing ILocation and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - Hanno continues working on this. See also: http://wiki.zope.org/zope2/SetParentAndNameInOFS +1 - Remove XML zexp export (davisagli). +1 - Catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection +0 - can we articulate the benefit of doing this? Currently items are keyed by path in ZCatalog as they must be pulled out with their correct acquisition context (five.intid must also maintain a mapping based on path for the same reason.) When we have parent pointers we will be able to use zope.intid directly instead of five.intid (which many of us have had bad experiences with.) Using intids will mean that renaming or moving items does not require them to be unindexed and reindexed in the portal_catalog as they will maintain their same intid and will open up the possibility of intersecting result sets from a the portal_catalog with a zc.relation catalog. - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. +1 - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. +1, though we'll need to balance the desire to be a better WSGI citizen with adding yet more complexity to BaseRequest and BaseResponse. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. +1 - I think WSGI should be the only way to deploy Zope 4. - Decorators for AccessControl (chaoflow). +1 Future releases (Zope 5, 6, etc.) - There has been some discussion on these topics but not much in the way of code yet: - Traversal Simplification. Remove attribute lookup from default traversal. +1, although this will require a lot of fixes in Zope consumers. I think we need a substantially simpler traversal mechanism that people actually understand. I've pdb'd BaseRequest.traverse more times than I care to remember and I still only vaguely understand it. - Unicode IDs in OFS +1 - Remove __allow_access_to_unprotected_subobjects__=1 from OFS.SimpleItem.Item +1, though again will break quite a lot. It's scary from a security perspective, though. - New ZMI +0 - we certainly need better XSRF protection and accessibility and look and feel are not great, though I think we should also consider what we actually use the ZMI for. A low-level object browser is really useful as a last resort admin tool. A number of the other things (like the various CMF tools, PAS, etc) could just as well expose their own views more independently of the ZMI, though we'd still need a way to discover those views. Perhaps something more simliar to the Plone control panel where tools can register views that just appear in a list of things you may need to manage may be useful, but it'll need some way of rooting that to e.g. Plone sites. - Move authentication out to WSGI middleware. +1 - anything we can do to make AccessControl simpler and more debuggable would be a big win. Long term - - Move to WebOb as our request object. The wider Python web framework community seems to have settled on WebOb as their request object of choice, so to facilitate sharing of software components with other projects we should consider making WebOb our request object too (instead of just wrapping it). This will require buy-in from
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 19:45, Tres Seaver tsea...@palladion.com wrote: Again, this is a choice to be made by the foundation: any polling will be done by the members of the foundation (this might be the biggest non-election item on the agenda for the next annual meeting). When is the next annual meeting? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4 release management
On 17 November 2011 20:20, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 03:14 PM, Laurence Rowe wrote: On 17 November 2011 19:45, Tres Seaver tsea...@palladion.com wrote: Again, this is a choice to be made by the foundation: any polling will be done by the members of the foundation (this might be the biggest non-election item on the agenda for the next annual meeting). When is the next annual meeting? Q1 2012 (date still to be set by the board). Is there any possibility the board could poll the members of the Zope Foundation between annual meetings? We're not looking to migrate the whole of svn.zope.org, only use github for what is essentially a new project. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
On 16 November 2011 10:30, Christian Theune c...@gocept.com wrote: Hi, I'd like to revert the removal of the ++skin++ traverser in Zope 4. As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature. From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework. I couldn't find an argument anywhere why ++skin++ should be gone. It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Revert removal of ++skin++ in Zope4?
On 16 November 2011 12:28, Lennart Regebro rege...@gmail.com wrote: On Wed, Nov 16, 2011 at 12:53, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro rege...@gmail.com: Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me. Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box. When I said skins I meant ++skins++. CMF Skins must die. While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/elro-parent-pointers/ New branch for adding parent pointers to Zope
Log message for revision 123200: New branch for adding parent pointers to Zope Changed: A Zope/branches/elro-parent-pointers/ -=- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/elro-parent-pointers/src/OFS/ Set parent pointers
Log message for revision 123223:
Set parent pointers
Changed:
U Zope/branches/elro-parent-pointers/src/OFS/Application.py
U Zope/branches/elro-parent-pointers/src/OFS/ObjectManager.py
U Zope/branches/elro-parent-pointers/src/OFS/tests/testApplication.py
U Zope/branches/elro-parent-pointers/src/OFS/tests/testObjectManager.py
-=-
Modified: Zope/branches/elro-parent-pointers/src/OFS/Application.py
===
--- Zope/branches/elro-parent-pointers/src/OFS/Application.py 2011-10-31
23:46:54 UTC (rev 123222)
+++ Zope/branches/elro-parent-pointers/src/OFS/Application.py 2011-11-01
00:54:04 UTC (rev 123223)
@@ -33,6 +33,7 @@
from zope.globalrequest import getRequest
from zope.interface import implements
+from zope.location.interfaces import ILocation
import Folder
import misc_
@@ -51,13 +52,18 @@
):
Top-level system object
-implements(IApplication)
+implements(
+IApplication,
+ILocation,
+)
security = ClassSecurityInfo()
title = 'Zope'
__defined_roles__ = ('Manager', 'Anonymous', 'Owner')
__error_log__ = None
+__name__ = None
+__parent__ = None
isTopLevelPrincipiaApplicationObject = 1
manage_options=((
Modified: Zope/branches/elro-parent-pointers/src/OFS/ObjectManager.py
===
--- Zope/branches/elro-parent-pointers/src/OFS/ObjectManager.py 2011-10-31
23:46:54 UTC (rev 123222)
+++ Zope/branches/elro-parent-pointers/src/OFS/ObjectManager.py 2011-11-01
00:54:04 UTC (rev 123223)
@@ -49,11 +49,14 @@
from webdav.Lockable import ResourceLockedError
from webdav.NullResource import NullResource
from zExceptions import BadRequest
+from zope.interface import alsoProvides
from zope.interface import implements
from zope.component.interfaces import ComponentLookupError
from zope.event import notify
from zope.lifecycleevent import ObjectAddedEvent
from zope.lifecycleevent import ObjectRemovedEvent
+from zope.location.interfaces import IContained
+from zope.location.interfaces import ILocation
from zope.container.contained import notifyContainerModified
from OFS.CopySupport import CopyContainer
@@ -274,10 +277,36 @@
_checkId = checkValidId
+def _contained(self, id, object):
+if ILocation.providedBy(object):
+if not ILocation.providedBy(self):
+raise AssertionError(
+Cannot add an object providing ILocation to an
+unlocated container.
+)
+if not IContained.providedBy(object):
+alsoProvides(object, IContained)
+oldparent = getattr(aq_base(object), '__parent__', None)
+if aq_base(self) is not aq_base(oldparent):
+aq_base(object).__parent__ = aq_base(self)
+# __name__ assumed to be a property or set elsewhere
+
def _setOb(self, id, object):
+self._contained(id, object)
setattr(self, id, object)
+def _uncontained(self, id):
+obj = self._getOb(id, _marker)
+if obj is not _marker:
+if IContained.providedBy(obj):
+try:
+aq_base(obj).__parent__ = None
+except AttributeError:
+# No need to fail if we can't set these
+pass
+
def _delOb(self, id):
+self._uncontained(id)
delattr(self, id)
def _getOb(self, id, default=_marker):
Modified: Zope/branches/elro-parent-pointers/src/OFS/tests/testApplication.py
===
--- Zope/branches/elro-parent-pointers/src/OFS/tests/testApplication.py
2011-10-31 23:46:54 UTC (rev 123222)
+++ Zope/branches/elro-parent-pointers/src/OFS/tests/testApplication.py
2011-11-01 00:54:04 UTC (rev 123223)
@@ -102,6 +102,12 @@
self.assertTrue(isinstance(result, NullResource))
self.assertTrue(aq_parent(aq_inner(result)) is app)
+def test_name_parent(self):
+app = self._makeOne()
+self.assertEquals(app.__name__, None)
+self.assertEquals(app.__parent__, None)
+
+
def _noWay(self, key, default=None):
raise KeyError(key)
Modified: Zope/branches/elro-parent-pointers/src/OFS/tests/testObjectManager.py
===
--- Zope/branches/elro-parent-pointers/src/OFS/tests/testObjectManager.py
2011-10-31 23:46:54 UTC (rev 123222)
+++ Zope/branches/elro-parent-pointers/src/OFS/tests/testObjectManager.py
2011-11-01 00:54:04 UTC (rev 123223)
@@ -13,6 +13,7 @@
from zExceptions import BadRequest
from zope.component.testing import PlacelessSetup
from zope.interface import implements
+from zope.location.interfaces import ILocation
from Zope2.App import zcml
from OFS.interfaces import IItem
@@ -70,6 +71,11 @@
[Zope-Checkins] SVN: Zope/branches/elro-parent-pointers/src/OFS/tests/testCopySupport.py Avoid makerequest so app is root object (other tests should also avoid this to match the new reality.)
Log message for revision 123224: Avoid makerequest so app is root object (other tests should also avoid this to match the new reality.) Changed: U Zope/branches/elro-parent-pointers/src/OFS/tests/testCopySupport.py -=- Modified: Zope/branches/elro-parent-pointers/src/OFS/tests/testCopySupport.py === --- Zope/branches/elro-parent-pointers/src/OFS/tests/testCopySupport.py 2011-11-01 00:54:04 UTC (rev 123223) +++ Zope/branches/elro-parent-pointers/src/OFS/tests/testCopySupport.py 2011-11-01 01:00:19 UTC (rev 123224) @@ -11,10 +11,11 @@ from OFS.Application import Application from OFS.Folder import manage_addFolder from OFS.Image import manage_addFile -from Testing.makerequest import makerequest +from Testing.makerequest import newrequest from zope import component from zope.testing import cleanup from persistent import Persistent +from zope.globalrequest import setRequest from zope.location import Location @@ -82,7 +83,9 @@ r['Application'] = a self.root = a responseOut = self.responseOut = cStringIO.StringIO() -self.app = makerequest( self.root, stdout=responseOut ) +request = newrequest(stdout=responseOut) +setRequest(request) +self.app = a manage_addFolder( self.app, 'folder1' ) manage_addFolder( self.app, 'folder2' ) folder1 = getattr( self.app, 'folder1' ) @@ -111,6 +114,7 @@ del self.responseOut del self.root del self.connection +setRequest(None) cleanup.cleanUp() ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] [Zope] Hotfix for security vulnerability
On 24 October 2011 22:54, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Zope security response team, I would like to announce the availability of a hotfix for a vulnerability inadvertently published earlier today. 'Products.Zope_Hotfix_20111024' README == Overview - This hotfix addresses a serious vulnerability in the Zope2 application server. Affected versions of Zope2 include: - - 2.12.x = 2.12.20 - - 2.13.x = 2.13.6 Older releases (2.11.x, 2.10.x, etc.) are not vulnerable. Can you confirm whether or not Zope 2.13.6 through 2.13.10 are affected? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Hotfix for security vulnerability
On 24 October 2011 22:54, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Zope security response team, I would like to announce the availability of a hotfix for a vulnerability inadvertently published earlier today. 'Products.Zope_Hotfix_20111024' README == Overview - This hotfix addresses a serious vulnerability in the Zope2 application server. Affected versions of Zope2 include: - - 2.12.x = 2.12.20 - - 2.13.x = 2.13.6 Older releases (2.11.x, 2.10.x, etc.) are not vulnerable. Can you confirm whether or not Zope 2.13.6 through 2.13.10 are affected? Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] serious security hole in manage users / Manage users permissions?
Potential security issues should not be discussed on public mailing lists but submitted to security-respo...@zope.org. Please submit the full information to that address and do not follow up further on this list. Laurence On 24 October 2011 15:05, Niels Dettenbach n...@syndicat.com wrote: Dear Zope 2.12/.13 (4.0) devels, as far as i can see i may have found a serious security hole within Zope 2.12 / 2.13 (4.0 not tested yet) - I'm still investigate here further... problem: == Even on fresh Installs of Zope and fresh created instances on it anonymous / remote users able to access acl_users/manage_users by the web WITHOUT AUTHENTICATION. They can edit / delete / create users and serving roles as they want. Other management screens (as manage_main or manage_access aso. are protected as usual). In manage_access Manage user is only allowed for Manager (as by default). I don't believe that is any new behaviour of newer Zope versions... I've tested this with (last public) 2.13.10 and last 2.12.20 with python2.6. If any of the devels want to have a test url pls contact me directly. Fresh installed zope instances was configured with defaults configs, except setting user zope (and/or port-base). Tried it with now owner or the admin user as owner of the acl_users too. Can anyone prove this here too? If so, any solution / security fix? many thanks, best regards. Niels. -- --- Niels Dettenbach Syndicat ITInternet http://www.syndicat.com/ ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] [collective.recipe.solrinstance] Example not working
On 17 October 2011 18:36, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, Oct 17, 2011 at 11:19 AM, Andreas Jung li...@zopyx.com wrote: I used the single-core example for the solrinstance recipe: I think someone reported the Solr core examples to be broken in the latest releases. I don't use the core-variants myself, though. Without an issue tracker, it's hard to keep track of those reports. Should we migrate the recipe to github and get a free issue tracker? +1 Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Error Migration Data.fs from Zope 2.10.4 to 2.13.8
You probably need to run it using ZODB 3.8 (i.e. with your Zope 2.10 instance.) Laurence On 6 October 2011 13:31, Frank Kauff fka...@biologie.uni-kl.de wrote: Unfortunately, it's not working: When starting within the 2.10.4 environment, I get the error Traceback (most recent call last): File ../strip_versions.py, line 116, in ? main() File ../strip_versions.py, line 108, in main ZODB.BaseStorage.copy(it, output_storage) AttributeError: 'module' object has no attribute 'copy' Starting it from within 2.13.8, I get the old error again: Traceback (most recent call last): File ../strip_versions.py, line 116, in module main() File ../strip_versions.py, line 108, in main ZODB.BaseStorage.copy(it, output_storage) File /opt/zope/lib/python2.6/site-packages/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZODB/BaseStorage.py, line 394, in copy for r in transaction: File ../strip_versions.py, line 57, in __iter__ for record in self.__transaction: File /opt/zope/lib/python2.6/site-packages/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZODB/FileStorage/FileStorage.py, line 1890, in next h = self._read_data_header(pos) File /opt/zope/lib/python2.6/site-packages/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZODB/FileStorage/format.py, line 150, in _read_data_header h = DataHeaderFromString(s) File /opt/zope/lib/python2.6/site-packages/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZODB/FileStorage/format.py, line 236, in DataHeaderFromString return DataHeader(*struct.unpack(DATA_HDR, s)) File /opt/zope/lib/python2.6/site-packages/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZODB/FileStorage/format.py, line 246, in __init__ Non-zero version length. Versions aren't supported.) ValueError: Non-zero version length. Versions aren't supported. Any help appreciated, Frank On 10/06/2011 02:02 PM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Try the following script to stip off versions: http://svn.zope.org/ZODB/branches/3.8/src/ZODB/scripts/strip_versions.py?rev=102805view=markup - -aj Frank Kauff wrote: Hi all, I'm trying to update from Zope 2.10.4 to 2.13.8 and have problems to copy Data.fs. No matter whether I try to directly copy Data.fs or use repozo, both times zope gives me the error ValueError: Non-zero version length. Versions aren't supported. Searching the net, this seems to be a common problem. However, I couldn't find a solution for it. Is there a tool anywhere that can convert Data.fs from older to newer formats? Thanks, Frank ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev ) - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope Plone D-72070 Tübingen | Produce Publish www.zopyx.com | www.produce-and-publish.com - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJOjZjeAAoJEADcfz7u4AZjCvILwLgI+0BJRDDYsP5Ygo19Sp2g D8EJg3vLup617HNFp2x9+ISfTy1QrNYmj/J204IUtuInD1AK0LV9s+UzYvivsYcW AdH0ordLSFSkMgPrEpAxJGfREd4+Qpy9LrTrqQ3stucQSOhl9+TkTzo8P0h/XWya YRpISUb5TIpUU6BwEqw8VcIzMamjkBzI/DY402J9OLsN/WcFO4RA5wQB6Rab5pyC LtYlEiZny1kAMtLc5DNu+0kWZ8tfkWyj4AgCJEkEDeQTE9VVNBN27zmSpmyk4g2F q8yHYH/o7e5rKDbjQ+9klgqX+XaMeIdyBs9opmZRtiwgC20H8Nq/oPpAuq6UpcZS alzjYg63cQzXqTLARdzJe0DBUFlvAHPFnFTlPOLk25CxQoZT+QdVLqF8yOw6pJ2U egCD2wg1B97M9sE6+payKm2aYyrc8Da13kTiPKa6sBdoHmSYUKyCS+PKcrkCnCMb 4Yrhqpq8DRDY8zlINlR/Nd/O29bRqj0= =GYbG -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Migration Data.fs from Zope 2.10.4 to 2.13.8
On 6 October 2011 14:40, Frank Kauff fka...@biologie.uni-kl.de wrote: On 10/06/2011 03:21 PM, Laurence Rowe wrote: You probably need to run it using ZODB 3.8 (i.e. with your Zope 2.10 instance.) I think that's what did: /opt/Zope-2.10/bin/python ../strip_versions.py Data.fs Data.fs.stripped which gave the first error below Or should I run it differently? Zope 2.10 shipped with ZODB 3.7.x and only worked with Python 2.4. Your error message is showing a problem in ZODB 3.10.3 for python 2.6. I think you're running it in your Zope 2.13 buildout. The strip_versions.py script needs to run with a ZODB released before version support was removed. The script shipped with ZODB 3.8.x but I expect it will also work with 3.7.x. Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Migration Data.fs from Zope 2.10.4 to 2.13.8
Perhaps you can just create a simple buildout.cfg for the version of ZODB you need: [buildout] parts = scripts versions = versions [versions] ZODB3 = 3.8.6 [scripts] recipe = zc.recipe.egg eggs = ZODB3 interpreter = py Grab bootstrap.py from http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py then run python bootstrap.py followed by bin/buildout. That should give you bin/strip_versions which you can run. Laurence On 6 October 2011 19:22, Frank Kauff fka...@biologie.uni-kl.de wrote: Hi Laurence, Please note that there are two errrors: The error versions not supported comes from Zope 2.13, but the other error appears when running from 2.10, with ZODB 3.7: [fkauff@aftol2 var]$ /opt/Zope-2.10/bin/python Python 2.4.3 (#1, Sep 21 2011, 19:55:41) [GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux2 Type help, copyright, credits or license for more information. import ZODB ZODB.__version__ '3.7.1' [fkauff@aftol2 var]$ /opt/Zope-2.10/bin/python ../strip_versions.py Data.fs Data.fs.stripped No handlers could be found for logger ZODB.FileStorage Traceback (most recent call last): File ../strip_versions.py, line 115, in ? main() File ../strip_versions.py, line 107, in main ZODB.BaseStorage.copy(it, output_storage) AttributeError: 'module' object has no attribute 'copy' I installed Zope 2.11 from old.zope.org, but it still comes with ZODB 3.7 [fkauff@aftol2 ~]$ /opt/Zope-2.11/bin/python Python 2.4.6 (#1, Oct 6 2011, 09:13:36) [GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux2 Type help, copyright, credits or license for more information. import ZODB ZODB.__version__ '3.7.0b3' ZODB.__path__ ['/opt/Zope-2.11/lib/python/ZODB'] So the main question seems to be - which Zope version is old enough to be able to read my Data.fs but recent enough to run the conversion script? Can i get a 2.11 version with ZODB 3.8 from somewhere? Thanks, Frank On 10/06/2011 05:54 PM, Laurence Rowe wrote: On 6 October 2011 14:40, Frank Kaufffka...@biologie.uni-kl.de wrote: On 10/06/2011 03:21 PM, Laurence Rowe wrote: You probably need to run it using ZODB 3.8 (i.e. with your Zope 2.10 instance.) I think that's what did: /opt/Zope-2.10/bin/python ../strip_versions.py Data.fs Data.fs.stripped which gave the first error below Or should I run it differently? Zope 2.10 shipped with ZODB 3.7.x and only worked with Python 2.4. Your error message is showing a problem in ZODB 3.10.3 for python 2.6. I think you're running it in your Zope 2.13 buildout. The strip_versions.py script needs to run with a ZODB released before version support was removed. The script shipped with ZODB 3.8.x but I expect it will also work with 3.7.x. Laurence -- J-Prof. Dr. Frank Kauff Molecular Phylogenetics FB Biologie, 13/276 TU Kaiserslautern Postfach 3049 67653 Kaiserslautern Tel. +49 (0)631 205-2562 Fax. +49 (0)631 205-2998 email:fka...@biologie.uni-kl.de skype: frank.kauff ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] zope.sqlalchemy+py3 test failures.
On 29 September 2011 10:33, Chris McDonough chr...@plope.com wrote: On Tue, 2011-09-27 at 12:40 -0400, Tres Seaver wrote: This bootstrap is from Jim's '2' branch of zc.buildout: http://svn.zope.org/zc.buildout/branches/2/bootstrap/bootstrap.py?rev=121484view=auto It is designed to work with Py3k. I've replaced the bootstrap.py in the chrism-py3 branch of both the transaction package and the zope.sqlalchemy packages with that one, and everything looks good! I think we can probably merge both of these branches to their respective trunks and make releases. I have the necessary powers to do it for transaction; I'll try to track down elro to see if he's willing to do it for zope.sqlalchemy. I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy+py3 test failures.
On 29 September 2011 16:51, Chris Withers ch...@simplistix.co.uk wrote: It'd also be great if we could get support for SA 0.7+'s new events system... I'm not convinced this will give any benefit. Currently we just require: Session = scoped_session(sessionmaker(bind=engine, ... extension=ZopeTransactionExtension())) Instead we would require something like: Session = scoped_session(sessionmaker(bind=engine)) ext = ZopeTransactionExtension() event.listen(Session, after_attach, ext.after_attach) event.listen(Session, after_begin, ext.after_begin) event.listen(Session, after_flush, ext.after_flush) event.listen(Session, after_bulk_update, ext.after_bulk_update) event.listen(Session, after_bulk_delete, ext.after_bulk_delete) event.listen(Session, before_commit, ext.before_commit) Though this could become: Session = scoped_session(sessionmaker(bind=engine)) ZopeTransactionExtension(Session) I'm just not sure that it's worthwhile. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BlueBream] Referring to same interface using zope.schema.Object
On 22 July 2011 13:32, Joshua Immanuel j...@hipro.co.in wrote: Hello, On Fri, 2011-07-22 at 13:41 +0200, Jacob Holm wrote: On 2011-07-22 13:26, Brian Sutherland wrote: This would be my first guess: class INode(Interface): pass INode.parent = Object( title=uParent node, schema=INode ) INode.children = List( title=u'Child nodes', value_type=Object(schema=INode) ) The method suggested by Brian works without any issues. :) No, there are issues. Take this example: class ITest(Interface): ... title = schema.TextLine() ... ITest.names bound method InterfaceClass.names of InterfaceClass __main__.ITest ITest.names() ['title'] ITest.description = schema.Text() ITest.names() ['title'] The fields on an interface are not stored as attributes, but are accessible using item access, e.g: ITest['title']. You cannot assign that way though: ITest['description'] = schema.TextLine() Traceback (most recent call last): File console, line 1, in module TypeError: 'InterfaceClass' object does not support item assignment Adding to an interface requires messing with the '_InterfaceClass__attrs' attribute of the dictionary and is discouraged. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Publisher, WSGI and possibility for simplification
Breaking this out as the thread has got overlong. On 4 July 2011 09:49, Sylvain Viollon sylv...@infrae.com wrote: On Sun, 03 Jul 2011 01:09:17 -0400 Chris McDonough chr...@plope.com wrote: On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote: Hello, - Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2). I have my own WSGI implementation, since a while, that works perfectly (infrae.wsgi), and I still do use the VirtualHostMonster (you can trash all the other things). I agree that its code might not been the best in the world, but it works for the moment and does what it says (I would love to see shiftNameToApplication implemented with more than one pass). I will sad to learn that this goes away, if nothing replace it. I kind of don't like the WSGI approach of cutting the database, traversing, authorization, rewriting Zope 2 concepts into middleware as I think they don't really fit the design of pipes provided by the WSGI middleware concept (but I do use middlewares for other things with Zope 2). I was interested to see that Pyramid seems to be experimenting with a non-wsgi approach now too for transaction integration (http://groups.google.com/group/pylons-devel/browse_thread/thread/f05c56072e43f214/3006cbaf0258c568.) I really don't have enough experience with WSGI to know which is the best way to do it. I took a brief look at the documentation at http://www.infrae.com/download/tools/infrae.wsgi where some of the motivations behind it are mentioned. The builtin Zope2 WSGI publisher is still very new, and seems to have some rough edges still when running in mod_wsgi (possibly due to conflicts with Zope registered signal handlers.) Is it only that you think that the Zope2 WSGI publisher is not ready yet, or are there other problems? I'd certainly support simplifying the publisher, it has grown very complex as more and more functionality has been grafted on over the years. In the long run I'd much rather see something that only used __getitem__ for traversal and never getattr. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 20:21, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com wrote: I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with native interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal: I think what's going to stay is AccessControl, OFS (a bit lighter), ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of Zope Toolkit libraries like components, events, browser pages and so on. That's the kind of scope that should be possible to port to Python 3 and actually modernize enough to be understandable.(...) Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base? If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players. I think the problem with the current ZMI is that it brings in a whole load of dependencies that we don't otherwise need - if it were minimalistic it wouldn't be a problem. I'm all for someone writing a very simple object browser though, it would make a great optional package. I'm certainly interested in moving away from OFS in the medium term towards the much simpler ZTK / Pyramid approach of __getitem__ traversal. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 6 July 2011 15:27, Sascha Welter zopel...@betabug.ch wrote: I'm sorry, I don't really understand the current line of discussion yet. I see a lot of discussion which part is going to be cut out and dropped, or replaced. I haven't yet understood what's the end target for the project. So, are you guys expecting to get Zope into a shape where it will attract new users and be a viable player again? Or, isn't the line currently that nobody uses Zope for new projects anyway? In case that we believe that no new users are attracted to Zope, wouldn't that mean that resources should go to make Zope into a shape that helps existing applications run on Zope and survive? Modernize the code, but break as little as possible in the process. As someone said, what's the use for a company that has invested a lot of money in a Zope Product, if there is something called Zope around, but they can't use it without a major rewrite? In case all these changes are made to make Zope again into a shiny new framework that will attract new users, what's the use? Wouldn't people go to pyramid anyway? There they have all that stuff already - but right *now*. Looking at the descriptions here, in that line of thought and in the long run we'll end up with something like pyramid in a few years, only with a lot more disgruntled former users and much more confusion about the name. When you change the name in the end, you've come full circle anyway. Zope in it's current form is not maintainable in the long run. There are too many alternative ways of achieving the same thing. Over the next few years we will need to start moving to Python 3, and the only way to make that port possible is by reducing the size of the codebase. As a Plone developer, my interest is in how we make Zope into something that enables Plone to continue evolving and developing, to port to Python 3 and increasingly use more standard WSGI components. Rewriting in Pyramid is not an option for us, large rewrites generally fail (even if they do produce excellent new technology along the way...) Of course if people who have legacy applications want to continue maintaining a 'Classic' Zope 2 in it's current form then they are free to do so, but it won't happen without investment on their part. I expect they will have similar concerns to the Plone developers, and may find the same reduction and evolution approach to Zope useful. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope2 Sprint. 31 October - 2 November, San Francisco
To make the most of all those air miles for people attending the Plone Conference, I want to have a Zope2 Sprint on the preceding days (overlapping with the training.) Topics to include: * Making Acquisition optional * Adding __parent__ pointers (see http://wiki.zope.org/zope2/SetParentAndNameInOFS) * Further WSGI integration When? Monday 31 October - Wednesday 2 November. Where? Somewhere in San Francisco. Venue to be confirmed, possibly a co-working space. Hopefully we'll have about 6-12 people for a small and fairly focussed sprint. If you're interested please sign up on the co-activate page at http://coactivate.org/projects/san-francisco-zope-sprint Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 11:22, Jonas Meurer jo...@freesources.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2011 12:04, schrieb Hanno Schlichting: On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places. I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions. I agree with Jonas that any idea of giving a package named Zope2 a version number that is not 2.x is only going to lead to more confusion. For Zope2 we're used the x in 2.x.y being the major version now anyway, the next release should be 2.14. Lets stick with our convention until we have something that we really do want to promote to users outside the existing development community, I expect that will be a few years away yet. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 4 July 2011 13:04, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On the other hand, if we could get the ZTK version of this working (the one that used /++vh-host and /++vh-root url segments) I think it should be ok, and we could get rid of VHM completely. The BlueBream URL syntax is no better than the existing VHM syntax, it makes for insanely complex proxy configs. The repoze.vhm approach of using headers is much, much simpler. However we choose to integrate it (whether as middleware or some other way,) lets at least use the simple approach of setting headers or hard coding in paste/whatever config. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] is it possible to upgrade from 2.9 to 2.13?
On 4 July 2011 13:26, Fernando ferna...@cmartins.nl wrote: Stefan, thanks for your reply. In the meanwhile I was indeed able to put products in INSTANCE/Products (Zope 2.13.8). I did not know about that option you mention and I cannot check it now, but the Products from pypi were being recognised, as long as I put only the specific Product subfolder (not the whole pypi package which contains cruft for eggs, whatever else, I still don't fully understand). However, with ZSQL Methods, the situation is different. It contains the specific ZSQL Methods folder, but also Shared/DC/ZRDB. When loading, Zope complains it can't find the module ZRDB/Search.py (or something like that). So, ZSQLMethods depends on Shared, but Share is not being recognised (or at least not yet processed before ZSQL). How can I fix this? Somehow I guess the pypi package should be made an egg and dropped in lib/python2.6, and somehow configured. I couldn't yet find instructions on doing this for Zope. I've been trying to read about this whole new procedure[s] (setup tools, buildout, eggs, virtualenv, ???), but I have the impression the situation has been changing and it's quite hard to figure out what makes sense or works right now. I suggest using http://pypi.python.org/pypi/plone.recipe.zope2instance (it is not Plone specific) and referring to the Plone documentation for installing add-ons: http://plone.org/documentation/kb/add-ons/installing Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] is it possible to upgrade from 2.9 to 2.13?
On 4 July 2011 14:48, Fernando ferna...@cmartins.nl wrote: On Jul 4, 2011 13:30 Laurence Rowe l...@lrowe.co.uk wrote: I suggest using http://pypi.python.org/pypi/plone.recipe.zope2instance (it is not Plone specific) and referring to the Plone documentation for installing add-ons: http://plone.org/documentation/kb/add-ons/installing Thanks Lawrence, I have already a zope 2.13.7 installation following the instructions and using virtualenv. This seems to be an alternative to the buildout system explained in those links. There are several options in the add-ons page and I don't feel confident it really applies to my case: I would recommend using buildout, most people do, if you have problems it helps to be in the main stream. 1) what is the ZSQLMethods package in pypi? http://pypi.python.org/pypi/Products.ZSQLMethods/2.13.4. It's a zip with some egg-info stuff in there but it is not clear that it really is an egg (no .egg extension) This is a source distribution that a binary egg will be automatically built from. As you are using virtualenv you should be able to easy_install Products.ZSQLMethods in the same way you installed Zope2. (I hope you have some way of ensuring a consistent known good set of packages equivalent to the buildout versions.cfg, without it you are unlikely to get a working system.) 2) is Buildout compatible with virtualenv? The option to install an Egg without Buildout is not recommended over there. On my development machine I have a virtualenv python (using --no-site-packages) which I use to run buildout's bootstrap. Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-Annce] Security Hotfix 20110622 released
Last week, the Zope and Plone security teams announced the discovery of a serious security issue affecting all recent versions of Zope and Plone, as well as the planned release of a Hotfix to address this issue to be made today, June 28th at 1500 UTC. The Plone and Zope security teams are announcing that this security hotfix is now available for download. For full instructions on how to get and install the Hotfix, go here: http://plone.org/products/plone-hotfix/releases/20110622 To find out more about the details of the issue, answers to common questions and which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 Assistance in installing this hotfix is available free of charge via IRC in #plone-tuneup. If you don't have in-house server administrators or a service agreement supporting your website, you can find consultancy companies under the providers section of Plone.org - http://plone.org/support/network On behalf of the Zope and Plone security teams, Laurence ___ Zope-Announce maillist - Zope-Announce@zope.org https://mail.zope.org/mailman/listinfo/zope-announce Zope-Announce for Announcements only - no discussions (Related lists - Users: https://mail.zope.org/mailman/listinfo/zope Developers: https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Security announcement update
This is an update on today's security hotfix release. The fix will be released at 15:00 UTC today, Tuesday 28th June, 2011 (11:00am US EDT.) Updated versions of Zope 2 containing the security fix will be released at the same time. For details on which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 For installation instructions, please see: http://plone.org/products/plone-hotfix/releases/20110622 On behalf of the Zope and Plone security teams, Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope] Security announcement update
On 28 June 2011 14:40, Norbert Marrale norbertmarr...@yahoo.com wrote: This should be clarified too: You should, however, make sure that you are running either Zope 2.10.13 or Zope 2.11.8 and PluggableAuthService 1.5.5, 1.6.5 or 1.7.5 Why must PluggableAuthService (+ its dependencies) even be installed? The Plone Hotfix for CVE-2011-0720 included patches to PluggableAuthService. If you use PluggableAuthService outside of Plone then you need to update to a release that includes that fix. If you don't run PluggableAuthService it is not required to install it. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope] Security announcement update
This is an update on today's security hotfix release. The fix will be released at 15:00 UTC today, Tuesday 28th June, 2011 (11:00am US EDT.) Updated versions of Zope 2 containing the security fix will be released at the same time. For details on which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 For installation instructions, please see: http://plone.org/products/plone-hotfix/releases/20110622 On behalf of the Zope and Plone security teams, Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] [Zope-dev] Security announcement update
On 28 June 2011 14:40, Norbert Marrale norbertmarr...@yahoo.com wrote: This should be clarified too: You should, however, make sure that you are running either Zope 2.10.13 or Zope 2.11.8 and PluggableAuthService 1.5.5, 1.6.5 or 1.7.5 Why must PluggableAuthService (+ its dependencies) even be installed? The Plone Hotfix for CVE-2011-0720 included patches to PluggableAuthService. If you use PluggableAuthService outside of Plone then you need to update to a release that includes that fix. If you don't run PluggableAuthService it is not required to install it. Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Security Hotfix 20110622 released
Last week, the Zope and Plone security teams announced the discovery of a serious security issue affecting all recent versions of Zope and Plone, as well as the planned release of a Hotfix to address this issue to be made today, June 28th at 1500 UTC. The Plone and Zope security teams are announcing that this security hotfix is now available for download. For full instructions on how to get and install the Hotfix, go here: http://plone.org/products/plone-hotfix/releases/20110622 To find out more about the details of the issue, answers to common questions and which versions of Zope and Plone are affected, please see: http://plone.org/products/plone/security/advisories/20110622 Assistance in installing this hotfix is available free of charge via IRC in #plone-tuneup. If you don't have in-house server administrators or a service agreement supporting your website, you can find consultancy companies under the providers section of Plone.org - http://plone.org/support/network On behalf of the Zope and Plone security teams, Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] easy_install Zope glitch on Debian aqueeze
On 23 June 2011 23:39, Eric d'Halibut eric.hali...@gmail.com wrote: Testing an install of Zope on an up-to-date Debian squeeze install, I get this below. Versions include: python2.6 2.6.6-8+b1 gcc 4:4.4.5-1 Does this ring any bells with anyone? Did you install python2.6-dev? My current list for a fresh debian/ubuntu install is (including varnish / PIL requirements and tools): subversion mercurial git build-essential pkg-config wv xpdf lynx wget libxslt1-dev python2.6-dev libjpeg-dev zlib1g-dev libfreetype6-dev libncurses5-dev libpcre3-dev xsltproc nginx emacs23-nox ne byobu Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Security announcement
On behalf of the Plone and Zope Security Teams I'd like to draw your attention to a security announcement that has just been published. This is a pre-announcement only, it does not contain any vulnerability details. Your sites are a safe today as they were yesterday. However, as the problem that has been found is so serious we are giving you advance warning that a patch is upcoming and recommending that you plan a maintenance period for your sites to coincide with the full announcement on Tuesday next week. Full details are available at http://plone.org/products/plone/security/advisories/pre-announcement-20110622 You can feel free to ask more questions on the plone-users mailing list or in the #plone IRC channel about details and how to protect yourself, but it is important to make a plan for this now. It is important to plan down-time at the time specified in that announcement or your site will potentially be at risk - following the release of a hotfix for the previous serious security vulnerability we received reports of automated attacks on unpatched sites. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope] Security announcement
On behalf of the Plone and Zope Security Teams I'd like to draw your attention to a security announcement that has just been published. This is a pre-announcement only, it does not contain any vulnerability details. Your sites are a safe today as they were yesterday. However, as the problem that has been found is so serious we are giving you advance warning that a patch is upcoming and recommending that you plan a maintenance period for your sites to coincide with the full announcement on Tuesday next week. Full details are available at http://plone.org/products/plone/security/advisories/pre-announcement-20110622 You can feel free to ask more questions on the plone-users mailing list or in the #plone IRC channel about details and how to protect yourself, but it is important to make a plan for this now. It is important to plan down-time at the time specified in that announcement or your site will potentially be at risk - following the release of a hotfix for the previous serious security vulnerability we received reports of automated attacks on unpatched sites. Laurence ___ Zope maillist - Zope@zope.org https://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Sharing session between different zope servers
On 15 June 2011 19:05, Baiju M baiju.m.m...@gmail.com wrote: On Wed, Jun 15, 2011 at 11:07 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Wed, Jun 15, 2011 at 7:26 PM, Baiju M baiju.m.m...@gmail.com wrote: Is memcached a reliable storage for session data ? I would like to hear others experience with memcached as a reliable storage for session data. It depends on what kind of reliability you need. Generally your sessions should be short-lived and memcached is fine for that. Well, what about a persistent session storage for 20 minutes in memcached ? Do we have any control over when the keys are evicted ? I am just reading few articles related to this: http://sparklewise.com/?p=538 http://en.wikipedia.org/wiki/Slab_allocation http://code.google.com/p/memcached/wiki/MemcachedSlabAllocator If you don't supply the -M argument then memcached won't evict objects before their expiration time, but it may run out of memory. The new unlogged tables in Postgres 9.1 might be a great fit, though you'll still wipe sessions when you make changes to your infrastructure / restart stuff. But most sites can cope with that. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BlueBream] Reg. persisting data in ZODB via forms
On 9 June 2011 07:12, Joshua Immanuel j...@hipro.co.in wrote: Hello Jonah, On Wed, 2011-06-08 at 22:25 -0700, Jonah Crawford wrote: Ah yes you do that in the zcml right after you define your object in a class :) I am not aware of the zcml configuration that can mark a class as persistent. If you could explain, it would be helpful. ZCML is not relevant here. On Jun 8, 2011, at 10:23 PM, Joshua Immanuel wrote: I was trying to add a non persistent object to the BTreeContainer. I was of the notion that I don't need to make my object persistent explicitly, as I am adding it to the persistent btree container. The add operation was successful but the modify operation on my object failed to persist. Making my object persistent solved the issue. I derived my class from persistent.Persistent in order to make it persistent. Deriving your class from Persistent is normally the right choice. Storing immutable non-persistent objects such as strings, ints, floats or tuples of them also works without surprises. Storing mutable non-persistent objects in the ZODB is considered advanced usage and you must inform the persistence machinery on any modification. The best way to do this is to re-assign the non-persistent object to it's parent persistent object, causing the parent to be marked as modified. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On 8 June 2011 10:05, Joe Steeve j...@hipro.co.in wrote:
Hello Charlie,
On Wed, 2011-06-08 at 10:48 +0200, Charlie Clark wrote:
From memory I can recall something similar related to making changes
to copies of instance attributes but failing to apply them to
attributes and needing to specifically go context.attribute =
form_result for the changes to persist.
Supposing, we have a form action like:
@form.action('Apply')
def handle_edit(self, action, data):
self.context.name += Blah
This change is visible in subsequent requests. i.e if we view this
object via another form, we can see the modification. However, if we
restart the server (bluebream), this change is lost. The same thing
happens when we use form.applyData. If we 'notify'
ObjectModifiedEvent, this does not happen.
Since the object's modification is visible across requests, I am
assuming that the transaction mechanism 'did' apply the changes to the
object.
But, it did not get to the disk :-/
This looks like self.context is not an instance of a Persistent
subclass. Only Persistent subclasses know how to register their
changes with the ZODB. You see the change on subsequent requests
because the object remains in the object cache, as soon as it's parent
Persistent instance is invalidated, or the server restarted the
changes will disappear. Storing mutable non-persistent objects in the
ZODB requires some care, specifically you need to register the change
on the object's persistent parent. The easiest way to do this is to
assign it to the parent again, e.g. parent['child-name'] = child.
My guess is that the ObjectModifiedEvent is dispatched to your
object's parent and causes something to change there, with the side
effect of storing your updated object.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reg. persisting data in ZODB via forms
On 8 June 2011 20:47, Joe Steeve j...@hipro.co.in wrote: On Wed, 2011-06-08 at 14:48 +0100, Laurence Rowe wrote: A BTree efficiently stores a large number of key,value pairs because the storage is split across a number of persistent objects (buckets) each of which stores a part of the tree, so only the bucket that changes needs to be stored when a key,value is updated. See http://zodb.org/documentation/guide/modules.html#btrees-package and http://en.wikipedia.org/wiki/B%2B_tree Okay. So, if there are (say) 10 objects in a bucket. And, one of them changes. Then, are all 10 objects serialized again? If they are not persistent objects themselves then yes. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Metaclass resolution for InterfaceClass
On 1 May 2011 20:28, Laurence Rowe l...@lrowe.co.uk wrote: While experimenting with my InterfaceClass subclass I noticed that it was only being used when it was specified as the first of the bases. I believe this is because InterfaceClass is not a subclass of ``type``, so the normal metaclass derivation logic is not applied. The attached patch implements that logic in InterfaceClass.__new__, picking from the base metaclasses that metaclass which subclasses all other base metaclasses. I've reported this as https://bugs.launchpad.net/zope.interface/+bug/791218 so it does not get lost. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding a _frame argument to InterfaceClass.__init__ to make it subclassable
On 1 May 2011 01:06, Laurence Rowe l...@lrowe.co.uk wrote: Hi, I'd like to apply the attached patch to zope.interface trunk to make it more easily subclassable without having to copy and paste a chunk of its __init__ into the subclass' __init__. On closer inspection, this doesn't seem to be necessary. With python 2.6 when creating a class __module__ is inserted as an attribute. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Metaclass resolution for InterfaceClass
While experimenting with my InterfaceClass subclass I noticed that it was only being used when it was specified as the first of the bases. I believe this is because InterfaceClass is not a subclass of ``type``, so the normal metaclass derivation logic is not applied. The attached patch implements that logic in InterfaceClass.__new__, picking from the base metaclasses that metaclass which subclasses all other base metaclasses. Laurence metaclass_resolution.diff Description: Binary data ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Adding a _frame argument to InterfaceClass.__init__ to make it subclassable
Hi, I'd like to apply the attached patch to zope.interface trunk to make it more easily subclassable without having to copy and paste a chunk of its __init__ into the subclass' __init__. Motivating factor is: I need an Interface with a hook that gets called after InterfaceClass.__init__ to allow for: * Checking that field names supplied as tagged values from directives correspond to actual field names to detect typos. * Registering the Interface instance for further configuration to be executed by a zope.configuration action. (Subclass is http://dev.plone.org/plone/browser/plone.supermodel/branches/elro-directives/plone/supermodel/model.py#L52) Laurence InterfaceClass-frame.diff Description: Binary data ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/2.13/ ZPublisher: HTTPResponse.appendHeader now keeps header values to a single
Log message for revision 121447:
ZPublisher: HTTPResponse.appendHeader now keeps header values to a single
line by default to avoid causing problems for proxy servers which do not
correctly handle multi-line headers.
Changed:
U Zope/branches/2.13/doc/CHANGES.rst
U Zope/branches/2.13/src/ZPublisher/HTTPResponse.py
U Zope/branches/2.13/src/ZPublisher/tests/testHTTPResponse.py
-=-
Modified: Zope/branches/2.13/doc/CHANGES.rst
===
--- Zope/branches/2.13/doc/CHANGES.rst 2011-04-19 09:24:05 UTC (rev 121446)
+++ Zope/branches/2.13/doc/CHANGES.rst 2011-04-19 15:01:30 UTC (rev 121447)
@@ -15,6 +15,10 @@
Features Added
++
+- ZPublisher: HTTPResponse.appendHeader now keeps header values to a single
+ line by default to avoid causing problems for proxy servers which do not
+ correctly handle multi-line headers.
+
- Updated distributions:
- Products.ZCatalog = 2.13.9
Modified: Zope/branches/2.13/src/ZPublisher/HTTPResponse.py
===
--- Zope/branches/2.13/src/ZPublisher/HTTPResponse.py 2011-04-19 09:24:05 UTC
(rev 121446)
+++ Zope/branches/2.13/src/ZPublisher/HTTPResponse.py 2011-04-19 15:01:30 UTC
(rev 121447)
@@ -338,7 +338,7 @@
name = literal and name or key
self.headers[name] = value
-def appendHeader(self, name, value, delimiter=,):
+def appendHeader(self, name, value, delimiter=, ):
Append a value to an HTTP return header.
Set an HTTP return header name with value value,
@@ -353,7 +353,7 @@
headers = self.headers
if headers.has_key(name):
h = headers[name]
-h = %s%s\r\n\t%s % (h, delimiter, value)
+h = %s%s%s % (h, delimiter, value)
else:
h = value
self.setHeader(name,h, scrubbed=True)
Modified: Zope/branches/2.13/src/ZPublisher/tests/testHTTPResponse.py
===
--- Zope/branches/2.13/src/ZPublisher/tests/testHTTPResponse.py 2011-04-19
09:24:05 UTC (rev 121446)
+++ Zope/branches/2.13/src/ZPublisher/tests/testHTTPResponse.py 2011-04-19
15:01:30 UTC (rev 121447)
@@ -445,13 +445,13 @@
response = self._makeOne()
response.setHeader('foo', 'bar')
response.appendHeader('foo', 'foo')
-self.assertEqual(response.headers.get('foo'), 'bar,\r\n\tfoo')
+self.assertEqual(response.headers.get('foo'), 'bar, foo')
def test_appendHeader_w_existing_case_insenstative(self):
response = self._makeOne()
response.setHeader('xxx', 'bar')
response.appendHeader('XXX', 'foo')
-self.assertEqual(response.headers.get('xxx'), 'bar,\r\n\tfoo')
+self.assertEqual(response.headers.get('xxx'), 'bar, foo')
def test_appendHeader_drops_CRLF(self):
# RFC2616 disallows CRLF in a header value.
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Merge [121447] to trunk - ZPublisher: HTTPResponse.appendHeader now keeps header values to a single
Log message for revision 121448:
Merge [121447] to trunk - ZPublisher: HTTPResponse.appendHeader now keeps
header values to a single
line by default to avoid causing problems for proxy servers which do not
correctly handle multi-line headers. (Merged from 2.13 branch.)
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/ZPublisher/HTTPResponse.py
U Zope/trunk/src/ZPublisher/tests/testHTTPResponse.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2011-04-19 15:01:30 UTC (rev 121447)
+++ Zope/trunk/doc/CHANGES.rst 2011-04-19 15:05:26 UTC (rev 121448)
@@ -32,6 +32,10 @@
Features Added
++
+- ZPublisher: HTTPResponse.appendHeader now keeps header values to a single
+ line by default to avoid causing problems for proxy servers which do not
+ correctly handle multi-line headers. (Merged from 2.13 branch.)
+
- Add preliminary IPv6 support to ZServer.
- ZPublisher: If `IBrowserPage` is provided by a view, form input is decoded.
Modified: Zope/trunk/src/ZPublisher/HTTPResponse.py
===
--- Zope/trunk/src/ZPublisher/HTTPResponse.py 2011-04-19 15:01:30 UTC (rev
121447)
+++ Zope/trunk/src/ZPublisher/HTTPResponse.py 2011-04-19 15:05:26 UTC (rev
121448)
@@ -338,7 +338,7 @@
name = literal and name or key
self.headers[name] = value
-def appendHeader(self, name, value, delimiter=,):
+def appendHeader(self, name, value, delimiter=, ):
Append a value to an HTTP return header.
Set an HTTP return header name with value value,
@@ -353,7 +353,7 @@
headers = self.headers
if headers.has_key(name):
h = headers[name]
-h = %s%s\r\n\t%s % (h, delimiter, value)
+h = %s%s%s % (h, delimiter, value)
else:
h = value
self.setHeader(name,h, scrubbed=True)
Modified: Zope/trunk/src/ZPublisher/tests/testHTTPResponse.py
===
--- Zope/trunk/src/ZPublisher/tests/testHTTPResponse.py 2011-04-19 15:01:30 UTC
(rev 121447)
+++ Zope/trunk/src/ZPublisher/tests/testHTTPResponse.py 2011-04-19 15:05:26 UTC
(rev 121448)
@@ -445,13 +445,13 @@
response = self._makeOne()
response.setHeader('foo', 'bar')
response.appendHeader('foo', 'foo')
-self.assertEqual(response.headers.get('foo'), 'bar,\r\n\tfoo')
+self.assertEqual(response.headers.get('foo'), 'bar, foo')
def test_appendHeader_w_existing_case_insenstative(self):
response = self._makeOne()
response.setHeader('xxx', 'bar')
response.appendHeader('XXX', 'foo')
-self.assertEqual(response.headers.get('xxx'), 'bar,\r\n\tfoo')
+self.assertEqual(response.headers.get('xxx'), 'bar, foo')
def test_appendHeader_drops_CRLF(self):
# RFC2616 disallows CRLF in a header value.
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] [Zope2] Multiline response headers causing problems for proxies.
On 18 April 2011 17:01, Laurence Rowe l...@lrowe.co.uk wrote: When using response.appendHeader, Zope appends the new value following an ,\r\n\t which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value. In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: Applications ought to follow common form, where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything Are there any objections to me applying the attached patch to Zope 2.13 and trunk? Laurence [1] http://www.varnish-cache.org/trac/ticket/905 [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html [3] http://tools.ietf.org/html/rfc1945#section-4.2 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html I've now applied this to 2.13 and trunk. If it causes any problems, let me know. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-CMF] CMF 2.3 plans?
Hi, What are the CMF 2.3 release plans? If we wanted to consider this for Plone 4.2 we would need a release fairly soon so we could make the required changes around member handling. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.3 plans?
On 19 April 2011 12:50, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 19.04.2011, 13:41 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: Hi Laurence, I could create a first alpha release for the various packages if that helps. For the first beta a.k.a. trunk branch point I need to know if anyone is working on features that are not on the trunk yet. Please speak up if branching for CMF 2.3 needs to be delayed. AFAIK the major block to a release is the stuff I need to tidy up in my browser-views only skin plus an upgrade step from old-style SyndicationInfo to an adapter based one. It's all on trunk and Yuppie has kindly done most(?) of the tidying up necessary but I still need to find the time insert excuse here to finish up the bits. Laurence, what timescale are you looking at? I think we would need to get to a CMF beta in the next couple of months to have a realistic chance of getting this into Plone 4.2. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-dev] [Zope2] Multiline response headers causing problems for proxies.
When using response.appendHeader, Zope appends the new value following an ,\r\n\t which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value. In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: Applications ought to follow common form, where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything Are there any objections to me applying the attached patch to Zope 2.13 and trunk? Laurence [1] http://www.varnish-cache.org/trac/ticket/905 [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html [3] http://tools.ietf.org/html/rfc1945#section-4.2 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html appendHeader.patch Description: Binary data ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope2] Multiline response headers causing problems for proxies.
On 18 April 2011 19:36, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/18/2011 12:01 PM, Laurence Rowe wrote: When using response.appendHeader, Zope appends the new value following an ,\r\n\t which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value. In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: Applications ought to follow common form, where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything Are there any objections to me applying the attached patch to Zope 2.13 and trunk? +0. We likely need to test that your patch doesn't break stuff on other maybe-not-compliant servers (older Apache, IIS). I don't think there is any risk of this. Plone's CacheFu has always generated the Cache-Control header as a single line, e.g. Cache-Control:max-age=0, s-maxage=0, must-revalidate and that has never caused a problem. The problem only rarely shows up because appendHeader is very rarely called, normally setHeader is used. In fact the only usage of it I could find of appendHeader in my egg cache or the entire Zope2 / Plone is in ZPublisher.HTTPResponse where it is called when gzipping the response (to add 'Accept-Encoding' to the Vary). Even then, it only causes a mulit-line header to be generated when you've already set Vary to something else (for instance Accept-Language.) For servers acting as pure proxies, the header value is opaque, so there is no risk. The only possible way a problem could arise is if they interpret the value in the header. Given that the only time this ever happens is with the Vary header, then only caching proxy servers need worry us. Given that they already cope just fine with the usual , delimited list of values in the Cache-Control header, I don't think compatibility issues need worry us here. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Ensuring at least min_length subwidgets are rendered for the MultiWidget
The attached patch ensures that when in input mode, the MultiWidget will render at least field.min_length subwidgets. This streamlines the add process, currently a user only finds out they need to add to a form when it is submitted and the error message is rendered. They must then make another request to actually get the add subform. I've not contributed much to z3c.form yet, so I wanted to check this approach looked reasonable before committing the patch. Laurence minwidgets.patch Description: Binary data ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 6 April 2011 22:24, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Ok, it starts making sense to me. What do you think about a class property like we us in fomr classes like ignoreContext, ignoreRequest, ignoreReadonly: ignoreProtection = True/False and set it by default to True? Or even to False and we can simply set it to True if test will fail because of changed form source? My current thinking is a modification of my first proposal above:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 16:53, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, April 04, 2011, Laurence Rowe wrote: The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. So why don't we make this a built-in feature then? The token manager (I think you call it the authenticator) needs to be smart, since it needs to deal with stale tokens and similar issues, but otherwise we could just add an authentication mechanism into z3c.form. Mmh, if the token gets stored in the session variable, then we do not even have to worry about token management, since the session container has already that logic. I have a feeling I am missing a level of complexity here... There should be no need to store anything in sessions, it really is as simple as ensuring that you include a signed token in the form submission that is separate from the user session identifier (as cookies get posted automatically on any form submission.) I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Not in my experience. In that case I will attempt to implement it in plone.z3cform first as that will allow me to just reuse the existing plone.protect stuff. My only concern really is how easy it will be to disable for individual forms - as I think it's important to have protection by default. I'm hoping that the following will work: * Register a ProtectedButtonActionHandler on z3c.form.form.Form (to be more specific than the default ButtonActionHandler registered on the IForm interface.) * Register the default ButtonActionHandler on a IUnprotectedForm interface, which individual forms can provide if they need to accept submissions from other sites. For a more general z3c.form protection scheme we can then look at making the zope2 dependencies in plone.protect optional. I would also like to change the token format of plone.protect to include the issue time, so secrets do not need to be rotated to invalidate old tokens, much as plone.session now does: http://pypi.python.org/pypi/plone.session Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] CSRF protection for z3c.form
I've been looking into how we might add CSRF protection to z3c.form forms as we will be including z3c.form in Plone 4.1. Currently in Plone, we use plone.protect to add an authentication token to our forms and then check the token in the methods that get called. (plone.protect is BSD licensed, but is Zope2 specific.) I think it's important for the integrator to be able to add an authentication policy to all z3c.form forms on a site, so I'd rather not rely on having all forms subclass some AuthenticatedForm. I can see a number of possible ways to implement this 1. Add a hook into z3c.form.form.Form along the lines of:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticator = zope.component.queryMultiAdapter( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) if authenticator is not None: authenticator.authenticate() This would allow integrators to register an ISubmissionAuthenticator that would be called when there are actions to execute (so not when a form is just displayed.) 2. Similar to (1) but fire an event. This would allow multiple submission authenticators to be registered (e.g. for post-only as well as check-authenticator), but this makes it more difficult to restrict authenticators to only certain forms / requests / contexts. 3. Register a more specific version of z3c.form.button.ButtonActionsHandler which performs the check before executing the handler. This has the advantage of not requiring any changes to z3c.form, but the disadvantages that: only button actions are protected, and would be executed per action handler execution instead of once per submission. I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 14:57, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, April 04, 2011, Laurence Rowe wrote: I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Hi Lawrence, I am okay with (1), but find (3) ore attractive. Since I am not familiar with the token solution to avoid CSRF attacks, can you briefly describe the sequence that is used to avoid those requests? Maybe we can some up with a tightly integrated solution. I have no problem with modifying z3c.form to support such a feature. Hi Stephen, The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 109 OK, 24 Failed, 4 Unknown
On 31 March 2011 10:15, Gediminas Paulauskas mene...@pov.lt wrote: 2011/3/23 Laurence Rowe l...@lrowe.co.uk: On 23 March 2011 14:43, Tres Seaver tsea...@palladion.com wrote: Multiple 'Content-Length' headers is definitely a Bad Thing. I filed a bug, which Mark Ramm has promised to escalate: https://sourceforge.net/apps/trac/sourceforge/ticket/18486 I have a patch for setuptools which works around it: http://bugs.python.org/setuptools/issue123 I'm not sure how to work around the issue at the moment. I always add the following to my buildout.cfg to avoid problems with random third party servers: allow-hosts = *.python.org *.plone.org launchpad.net (launchpad.net is there only for mocker which does not have a pypi release). I have added the following sites to allow-hosts for SchoolTool, that needs Sphinx, Pygments, PIL, reportlab, pyPdf, Paste. allow-hosts = buildout.org code.google.com effbot.org *.googlecode.com pybrary.net pygments.org *.python.org pythonpaste.org *.pythonware.com *.pocoo.org reportlab.com *.repoze.org *.schooltool.org Not all sites are needed, but why block projects official downloads? Limiting your allowed hosts to the minimal set makes running buildout much faster as most of the network requests get blocked. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/trunk/ Adding support for ``IStreamIterator`` to WSGI publishing machinery.
On 26 March 2011 17:14, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/26/2011 12:53 PM, Malthe Borch wrote: Log message for revision 121131: Adding support for ``IStreamIterator`` to WSGI publishing machinery. Changed: U Zope/trunk/doc/CHANGES.rst U Zope/trunk/src/ZPublisher/WSGIPublisher.py U Zope/trunk/src/ZPublisher/tests/test_WSGIPublisher.py -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2011-03-25 17:39:14 UTC (rev 121130) +++ Zope/trunk/doc/CHANGES.rst 2011-03-26 16:53:52 UTC (rev 121131) @@ -11,6 +11,10 @@ Bugs Fixed ++ +- Fix `WSGIResponse` and `publish_module` functions such that they + support the `IStreamIterator` interface in addition to `file` (as + supported by `ZServer.HTTPResponse`). + - Made sure getConfiguration().default_zpublisher_encoding is set correctly. - LP #713253: Prevent publication of acquired attributes, where the acquired Modified: Zope/trunk/src/ZPublisher/WSGIPublisher.py === --- Zope/trunk/src/ZPublisher/WSGIPublisher.py 2011-03-25 17:39:14 UTC (rev 121130) +++ Zope/trunk/src/ZPublisher/WSGIPublisher.py 2011-03-26 16:53:52 UTC (rev 121131) @@ -30,6 +30,7 @@ from ZPublisher.Publish import dont_publish_class from ZPublisher.Publish import get_module_info from ZPublisher.Publish import missing_name +from ZPublisher.Iterators import IStreamIterator _NOW = None # overwrite for testing def _now(): @@ -125,7 +126,7 @@ self.stdout.write(data) def setBody(self, body, title='', is_error=0): - if isinstance(body, file): + if isinstance(body, file) or IStreamIterator.providedBy(body): body.seek(0, 2) length = body.tell() body.seek(0) This part of the patch can't possibly work in the general case: nothing in IStreamIterator promises that 'seek' and 'tell' are available. In plone.subrequest, I need similar functionality. I ended up checking for seek before calling it and special casing a plone.app.blob iterator. http://dev.plone.org/plone/browser/plone.subrequest/trunk/plone/subrequest/subresponse.py Perhaps we want an extended sub-interface for IFileStreamIterator which defines seek(), tell() and read()? Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 109 OK, 24 Failed, 4 Unknown
On 23 March 2011 14:43, Tres Seaver tsea...@palladion.com wrote: Multiple 'Content-Length' headers is definitely a Bad Thing. I filed a bug, which Mark Ramm has promised to escalate: https://sourceforge.net/apps/trac/sourceforge/ticket/18486 I have a patch for setuptools which works around it: http://bugs.python.org/setuptools/issue123 I'm not sure how to work around the issue at the moment. I always add the following to my buildout.cfg to avoid problems with random third party servers: allow-hosts = *.python.org *.plone.org launchpad.net (launchpad.net is there only for mocker which does not have a pypi release). Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] GenericSetup global registries
On 8 March 2011 16:26, Wichert Akkerman wich...@wiggy.net wrote: On 2011-3-8 17:08, Godefroid Chapelle wrote: Hello, GenericSetup has global registries for profiles and steps. They are a PITA when testing. For instance, plone.app.testing has to make a complicated dance to record and restore their state. How come? There is a very simple cleanup function for them iirc? In branch gotcha-registries-use-utilities, I have removed those global storages. The profiles and steps are instead registered as global named utilities. I'm not convinced using the ZCA makes sense for this. The steps are a simple list of hooks indexed by name, and the ZCA is massive overkill for that purpose and very painful to introspect. While the ZCA registry may be overkill for a particular case in isolation, when Zope is taken as a whole it is simpler to deal with one registry implementation than many differing ones. So +1 for moving this to the global ZCA registry. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
On 2 March 2011 11:29, yuppie y.2...@wcm-solutions.de wrote: Laurence Rowe wrote: On 2 March 2011 10:00, yuppiey.2...@wcm-solutions.de wrote: Martin Aspeli wrote: I don't know what setPageEncoding() does, though. It sets a response Content-Type header with the first charset processInputs tries for decoding. Is the charset of the request necessarily the right choice for the response? In Plone we always serve UTF-8 encoded. getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is accepted. If 'utf-8' is not in getPreferredCharsets(), it is not very likely that the browser speaks UTF-8 and processInputs will not even try to decode with UTF-8. In that case it might be better to respond with an accepted encoding. If you serve differently encoded pages then you should set Vary: Accept-Charset. But then without normalization you'd get an explosion of different page variations. Without the Vary, it means that a visitor can poison the cache by supplying (only) a weird charset in Accept-Encoding. The page would then be served in this encoding, cached downstream, and if other visitor's browsers don't support that charset then they have a problem. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] string exceptions
On 25 February 2011 10:58, Godefroid Chapelle got...@bubblenet.be wrote: Hi, I find a few string exceptions leftover in Zope 2.13 code. However, they are not allowed anymore in Python 2.6. I guess that the remaining string exceptions are in dead/semidead code. What practice has been followed until now regarding fixing those exceptions ? According to this doc, http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release. It will of course be important to fix these before we move to Python 3.x, but I would expect that the dead/semidead code will not be ported. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] string exceptions
On 25 February 2011 11:03, Laurence Rowe l...@lrowe.co.uk wrote: On 25 February 2011 10:58, Godefroid Chapelle got...@bubblenet.be wrote: Hi, I find a few string exceptions leftover in Zope 2.13 code. However, they are not allowed anymore in Python 2.6. I guess that the remaining string exceptions are in dead/semidead code. What practice has been followed until now regarding fixing those exceptions ? According to this doc, http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release. It will of course be important to fix these before we move to Python 3.x, but I would expect that the dead/semidead code will not be ported. I take that back, that documentation is incorrect, they have indeed stopped working. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] string exceptions
On 25 February 2011 11:09, Godefroid Chapelle got...@bubblenet.be wrote: Le 25/02/11 12:03, Laurence Rowe a écrit : On 25 February 2011 10:58, Godefroid Chapellegot...@bubblenet.be wrote: Hi, I find a few string exceptions leftover in Zope 2.13 code. However, they are not allowed anymore in Python 2.6. I guess that the remaining string exceptions are in dead/semidead code. What practice has been followed until now regarding fixing those exceptions ? According to this doc, http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release. It will of course be important to fix these before we move to Python 3.x, but I would expect that the dead/semidead code will not be ported. Laurence I just tried to run the code hereunder with Python 2.6.5: def main(): raise Abc main() This is what I get : Traceback (most recent call last): File test.py, line 4, in module main() File test.py, line 2, in main raise Abc TypeError: exceptions must be old-style classes or derived from BaseException, not str I am not sure what the documentation above means but it seems to be text that was not fixed... Reported in http://bugs.python.org/issue11317 Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] string exceptions
On 25 February 2011 11:14, Godefroid Chapelle got...@bubblenet.be wrote: Le 25/02/11 12:03, Hanno Schlichting a écrit : I find a few string exceptions leftover in Zope 2.13 code. What practice has been followed until now regarding fixing those exceptions ? Just upgrade them to new-style exception classes. Since string exceptions cannot possibly work anymore, we cannot make things worse by fixing them. Hanno What about deciding to kill that code ? I guess it is a bit early because not enough people did migrate to 2.12 or later. These statements now raise a TypeError instead of a string exceotion, which in most cases should be functionally equivalent. There's no guarantee that the code is dead. Where should those fixes happen ? 2.13 branch and trunk I suppose This seems sensible. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-CMF] String exceptions
On 25 February 2011 10:53, Godefroid Chapelle got...@bubblenet.be wrote: Hi, Python2.6 has deprecated string exceptions. However, I find about 15 string exceptions in CMF 2.2 I guess this is just something that was forgotten. Can we consider this as a critical issue for next release ? It certainly seems worth updating these, but I wouldn't consider it critical. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] String exceptions
On 25 February 2011 14:08, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/25/2011 05:53 AM, Godefroid Chapelle wrote: Python2.6 has deprecated string exceptions. However, I find about 15 string exceptions in CMF 2.2 I guess this is just something that was forgotten. Can we consider this as a critical issue for next release ? Critial is not the right urgency for fixing deprecation warnings: nothing breaks, there is no security hole, etc. That being saie: you've done the hard work (finding them): just go ahead and check the fix in. As mentioned on the zope-dev list, string exceptions were actually removed int Python 2.6. I still don't think it's critical though, it just raises a TypeError now instead of a string exception. Laurence ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-dev] [ZODB-Dev] transaction as context manager, exception during commit
On 24 February 2011 10:17, Chris Withers ch...@simplistix.co.uk wrote: Hi Jim, The current __exit__ for transaction managers looks like this: def __exit__(self, t, v, tb): if v is None: self.commit() else: self.abort() ..which means that if you're using the transaction package as a context manager and, say, a relational database integrity constraint is violated, then you're left with a hosed transaction that still needs aborting. How would you feel about the above changing to: def __exit__(self, t, v, tb): if v is None: try: self.commit() except: self.abort() raise else: self.abort() If this is okay, I'll be happy to write the tests and make the changes provided someone does a release when I have... Looking at the way ZPublisher handles this, I think you're right. I think you might also need to modify the __exit__ in Attempt, which additionally handles retrying transactions that fail. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Time for a z3c.blobfile release
There have been a couple of fixes to z3c.blobfile. Would one of the package owners (uoestermeier, nadako) be able to make a new release to pypi? Thanks! Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt revert change to makesite.txt
Log message for revision 119840:
revert change to makesite.txt
Changed:
U
Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt
-=-
Modified:
Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt
===
---
Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt
2011-01-22 06:42:25 UTC (rev 119839)
+++
Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt
2011-01-22 16:47:05 UTC (rev 119840)
@@ -32,7 +32,6 @@
from Testing.testbrowser import Browser
browser = Browser()
- browser.handleErrors = False
browser.addHeader('Authorization', 'Basic manager:r00t')
Let's add a folder:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/src/OFS/Application.py Add an aq_explicit property to the Application object as it is not longer aq wrapped.
Log message for revision 119841: Add an aq_explicit property to the Application object as it is not longer aq wrapped. Changed: U Zope/branches/elro-remove-request-container/src/OFS/Application.py -=- Modified: Zope/branches/elro-remove-request-container/src/OFS/Application.py === --- Zope/branches/elro-remove-request-container/src/OFS/Application.py 2011-01-22 16:47:05 UTC (rev 119840) +++ Zope/branches/elro-remove-request-container/src/OFS/Application.py 2011-01-22 16:49:26 UTC (rev 119841) @@ -245,6 +245,14 @@ def REQUEST(self): del self.__dict__['REQUEST'] +@property +def aq_explicit(self): +# aq_explict is a property of acquisition wrappers. As the Application +# object is no longer wrapped in a RequestContainer, it must be +# supported directly. +return self + + InitializeClass(Application) ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/src/Testing/ revert changes to makerequest, need a different approach here
Log message for revision 119842:
revert changes to makerequest, need a different approach here
Changed:
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/sandbox.py
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
U Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
U
Zope/branches/elro-remove-request-container/src/Testing/tests/test_makerequest.py
-=-
Modified:
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/sandbox.py
===
---
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/sandbox.py
2011-01-22 16:49:26 UTC (rev 119841)
+++
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/sandbox.py
2011-01-22 16:59:32 UTC (rev 119842)
@@ -19,7 +19,9 @@
import utils
import connections
+from zope.globalrequest import setRequest, clearRequest
+
class Sandboxed:
'''Derive from this class and an xTestCase to make each test
run in its own ZODB sandbox::
@@ -32,7 +34,8 @@
'''Returns the app object for a test.'''
app = Zope2.app(Zope2.sandbox().open())
AppZapper().set(app)
-app = utils.makerequest(app)
+req = utils.newrequest()
+setRequest(req)
connections.register(app)
return app
@@ -41,6 +44,7 @@
AppZapper().clear()
transaction.abort()
connections.closeAll()
+clearRequest()
class AppZapper:
Modified:
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
===
---
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
2011-01-22 16:49:26 UTC (rev 119841)
+++
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
2011-01-22 16:59:32 UTC (rev 119842)
@@ -118,6 +118,16 @@
return _makerequest(app, stdout=stdout, environ=environ)
+def makerequest(stdout=sys.stdout):
+'''Wraps the app into a fresh REQUEST.'''
+from Testing.makerequest import newrequest as _newrequest
+environ = {}
+environ['SERVER_NAME'] = _Z2HOST or 'nohost'
+environ['SERVER_PORT'] = '%d' % (_Z2PORT or 80)
+environ['REQUEST_METHOD'] = 'GET'
+return _newrequest(stdout=stdout, environ=environ)
+
+
def appcall(func, *args, **kw):
'''Calls a function passing 'app' as first argument.'''
from base import app, close
Modified: Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
===
--- Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
2011-01-22 16:49:26 UTC (rev 119841)
+++ Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
2011-01-22 16:59:32 UTC (rev 119842)
@@ -19,7 +19,7 @@
from sys import stdin, stdout
from ZPublisher.HTTPRequest import HTTPRequest
from ZPublisher.HTTPResponse import HTTPResponse
-from zope.globalrequest import setRequest
+from ZPublisher.BaseRequest import RequestContainer
def makerequest(app, stdout=stdout, environ=None):
@@ -61,6 +61,6 @@
# Zope3-style view look-ups.
from zope.publisher.browser import setDefaultSkin
setDefaultSkin(req)
-setRequest(req)
-return app
+requestcontainer = RequestContainer(REQUEST = req)
+return app.__of__(requestcontainer)
Modified:
Zope/branches/elro-remove-request-container/src/Testing/tests/test_makerequest.py
===
---
Zope/branches/elro-remove-request-container/src/Testing/tests/test_makerequest.py
2011-01-22 16:49:26 UTC (rev 119841)
+++
Zope/branches/elro-remove-request-container/src/Testing/tests/test_makerequest.py
2011-01-22 16:59:32 UTC (rev 119842)
@@ -17,29 +17,24 @@
from Acquisition import Implicit
from Testing.makerequest import makerequest
-from OFS.Application import Application
-from zope.globalrequest import getRequest, clearRequest
+from OFS.SimpleItem import SimpleItem
class MakerequestTests(unittest.TestCase):
-def tearDown(self):
-clearRequest()
-
def test_makerequest(self):
# The argument must support acquisition.
-#self.assertRaises(AttributeError, makerequest, object())
+self.assertRaises(AttributeError, makerequest, object())
# After the call, it will have a REQUEST attribute.
-app = Application()
-self.assertFalse(hasattr(app, 'REQUEST'))
-app = makerequest(app)
-self.failUnless(getRequest() is not None)
-self.assertTrue(hasattr(app, 'REQUEST'))
+item = Implicit()
+self.assertFalse(hasattr(item, 'REQUEST'))
+item = makerequest(item)
+self.assertTrue(hasattr(item, 'REQUEST'))
def test_dont_break_getPhysicalPath(self):
# see
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/src/Testing/ Leave makerequest using a RequestContainer to support legacy tests; make ZopeTestCase set the global request instead. All
Log message for revision 119843:
Leave makerequest using a RequestContainer to support legacy tests; make
ZopeTestCase set the global request instead. All tests pass.
Changed:
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/base.py
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
U Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
-=-
Modified:
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/base.py
===
---
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/base.py
2011-01-22 16:59:32 UTC (rev 119842)
+++
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/base.py
2011-01-22 17:11:33 UTC (rev 119843)
@@ -107,7 +107,11 @@
def _app(self):
'''Returns the app object for a test.'''
-return app()
+app = Zope2.app()
+req = utils.newrequest()
+setRequest(req)
+connections.register(app)
+return app
def _setup(self):
'''Sets up the fixture. Framework authors may
Modified:
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
===
---
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
2011-01-22 16:59:32 UTC (rev 119842)
+++
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/utils.py
2011-01-22 17:11:33 UTC (rev 119843)
@@ -118,8 +118,8 @@
return _makerequest(app, stdout=stdout, environ=environ)
-def makerequest(stdout=sys.stdout):
-'''Wraps the app into a fresh REQUEST.'''
+def newrequest(stdout=sys.stdout):
+'''Creates a new request for testing'''
from Testing.makerequest import newrequest as _newrequest
environ = {}
environ['SERVER_NAME'] = _Z2HOST or 'nohost'
@@ -160,6 +160,7 @@
'importObjectFromFile',
'appcall',
'makerequest',
+'newrequest',
'makelist',
]
Modified: Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
===
--- Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
2011-01-22 16:59:32 UTC (rev 119842)
+++ Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
2011-01-22 17:11:33 UTC (rev 119843)
@@ -19,8 +19,41 @@
from sys import stdin, stdout
from ZPublisher.HTTPRequest import HTTPRequest
from ZPublisher.HTTPResponse import HTTPResponse
-from ZPublisher.BaseRequest import RequestContainer
+from ExtensionClass import Base
+class RequestContainer(Base):
+__roles__=None
+def __init__(self,**kw):
+for k,v in kw.items(): self.__dict__[k]=v
+
+
+def newrequest(stdout=stdout, environ=None):
+
+Creates a new request for testing.
+
+*stdout* is an optional file-like object and is used by
+REQUEST.RESPONSE. The default is sys.stdout.
+
+*environ* is an optional mapping to be used in the request.
+Default is a fresh dictionary. Passing os.environ is not
+recommended; tests should not pollute the real os.environ.
+
+if environ is None:
+environ = {}
+resp = HTTPResponse(stdout=stdout)
+environ.setdefault('SERVER_NAME', 'foo')
+environ.setdefault('SERVER_PORT', '80')
+environ.setdefault('REQUEST_METHOD', 'GET')
+req = HTTPRequest(stdin, environ, resp)
+req._steps = ['noobject'] # Fake a published object.
+req['ACTUAL_URL'] = req.get('URL') # Zope 2.7.4
+
+# set Zope3-style default skin so that the request is usable for
+# Zope3-style view look-ups.
+from zope.publisher.browser import setDefaultSkin
+setDefaultSkin(req)
+return req
+
def makerequest(app, stdout=stdout, environ=None):
Adds an HTTPRequest at app.REQUEST, and returns
@@ -47,20 +80,6 @@
Default is a fresh dictionary. Passing os.environ is not
recommended; tests should not pollute the real os.environ.
-if environ is None:
-environ = {}
-resp = HTTPResponse(stdout=stdout)
-environ.setdefault('SERVER_NAME', 'foo')
-environ.setdefault('SERVER_PORT', '80')
-environ.setdefault('REQUEST_METHOD', 'GET')
-req = HTTPRequest(stdin, environ, resp)
-req._steps = ['noobject'] # Fake a published object.
-req['ACTUAL_URL'] = req.get('URL') # Zope 2.7.4
-
-# set Zope3-style default skin so that the request is usable for
-# Zope3-style view look-ups.
-from zope.publisher.browser import setDefaultSkin
-setDefaultSkin(req)
-
+req = newrequest(stdout, environ)
requestcontainer = RequestContainer(REQUEST = req)
return app.__of__(requestcontainer)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/ Branch to experiment with adding a REQUEST property to the application object and remove the request container
Log message for revision 119791: Branch to experiment with adding a REQUEST property to the application object and remove the request container Changed: A Zope/branches/elro-remove-request-container/ -=- ___ Zope-Checkins maillist - Zope-Checkins@zope.org https://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/elro-remove-request-container/ Remove RequestContainer and make app.REQUEST a property looking up the globalrequest.
Log message for revision 119792:
Remove RequestContainer and make app.REQUEST a property looking up the
globalrequest.
This mostly works, but causes two problems:
1. Some very old request using Testing.makerequest are unable to clean up the
globalrequest after themselves, leading to failures because of lack of test
isolation.
2. The Application object itself is no longer aq wrapped, so does not have an
aq_explicit attribute.
(Part of http://wiki.zope.org/zope2/SetParentAndNameInOFS)
Changed:
U Zope/branches/elro-remove-request-container/setup.py
U Zope/branches/elro-remove-request-container/sources.cfg
U Zope/branches/elro-remove-request-container/src/OFS/Application.py
U
Zope/branches/elro-remove-request-container/src/Products/Five/browser/tests/aqlegacy_ftest.txt
U
Zope/branches/elro-remove-request-container/src/Products/Five/component/makesite.txt
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/base.py
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/connections.py
U
Zope/branches/elro-remove-request-container/src/Testing/ZopeTestCase/functional.py
U Zope/branches/elro-remove-request-container/src/Testing/makerequest.py
U
Zope/branches/elro-remove-request-container/src/Testing/tests/test_makerequest.py
U Zope/branches/elro-remove-request-container/src/ZPublisher/BaseRequest.py
U Zope/branches/elro-remove-request-container/src/ZPublisher/Publish.py
U Zope/branches/elro-remove-request-container/versions.cfg
-=-
Modified: Zope/branches/elro-remove-request-container/setup.py
===
--- Zope/branches/elro-remove-request-container/setup.py2011-01-20
15:36:14 UTC (rev 119791)
+++ Zope/branches/elro-remove-request-container/setup.py2011-01-20
15:40:54 UTC (rev 119792)
@@ -82,6 +82,7 @@
'zope.deferredimport',
'zope.event',
'zope.exceptions',
+ 'zope.globalrequest',
'zope.i18n [zcml]',
'zope.i18nmessageid',
'zope.interface',
Modified: Zope/branches/elro-remove-request-container/sources.cfg
===
--- Zope/branches/elro-remove-request-container/sources.cfg 2011-01-20
15:36:14 UTC (rev 119791)
+++ Zope/branches/elro-remove-request-container/sources.cfg 2011-01-20
15:40:54 UTC (rev 119792)
@@ -17,3 +17,4 @@
zExceptions = svn ^/zExceptions/trunk
ZODB3 = svn ^/ZODB/trunk
ZopeUndo = svn ^/ZopeUndo/trunk
+zope.globalrequest = svn ^/zope.globalrequest/trunk
Modified: Zope/branches/elro-remove-request-container/src/OFS/Application.py
===
--- Zope/branches/elro-remove-request-container/src/OFS/Application.py
2011-01-20 15:36:14 UTC (rev 119791)
+++ Zope/branches/elro-remove-request-container/src/OFS/Application.py
2011-01-20 15:40:54 UTC (rev 119792)
@@ -39,6 +39,7 @@
from webdav.NullResource import NullResource
from zExceptions import Redirect as RedirectException, Forbidden
+from zope.globalrequest import getRequest
from zope.interface import implements
import Folder
@@ -225,6 +226,25 @@
reg = {}
return reg.get(flag)
+@property
+def REQUEST(self):
+# Return the current request
+request = self.__dict__.get('REQUEST', None)
+if request is None:
+request = getRequest()
+if request is None:
+raise AttributeError('REQUEST')
+return request
+
+@REQUEST.setter
+def REQUEST(self, value):
+# Set the current request as an attribute (used in tests)
+self.__dict__['REQUEST'] = value
+
+@REQUEST.deleter
+def REQUEST(self):
+del self.__dict__['REQUEST']
+
InitializeClass(Application)
Modified:
Zope/branches/elro-remove-request-container/src/Products/Five/browser/tests/aqlegacy_ftest.txt
===
---
Zope/branches/elro-remove-request-container/src/Products/Five/browser/tests/aqlegacy_ftest.txt
2011-01-20 15:36:14 UTC (rev 119791)
+++
Zope/branches/elro-remove-request-container/src/Products/Five/browser/tests/aqlegacy_ftest.txt
2011-01-20 15:40:54 UTC (rev 119792)
@@ -23,8 +23,7 @@
print browser.contents
[Products.Five.metaclass.LegacyAttributes object at ...,
Folder at /test_folder_1_,
- Application at ,
- ZPublisher.BaseRequest.RequestContainer object at ...]
+ Application at ]
The same goes for browser views that just mix in Acquisition.Explicit:
@@ -32,8 +31,7 @@
print browser.contents
[Products.Five.metaclass.ExplicitLegacyAttributes object at ...,
Folder at /test_folder_1_,
- Application at ,
- ZPublisher.BaseRequest.RequestContainer object at ...]
+ Application at ]
Let's do some more manual tests with the view object. But first we
must get it:
Modified:
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
On 4 January 2011 13:00, yuppie y.2...@wcm-solutions.de wrote:
Hi!
Zope trunk (2.14) no longer ships with these Products:
Products.BTreeFolder2
Products.ExternalMethod
Products.MailHost
Products.MIMETools
Products.PythonScripts
Products.StandardCacheManagers
There are no separate Zope 2.12 compatible eggs for these Products
because they are part of the Zope2 2.12.X eggs.
Problem is: Several Products (e.g. CMF) exist that depend on these
Products and want to support Zope2 2.12, 2.13 and trunk. But AFAICS
there is no way to specify all dependencies correctly in setup.py. As a
workaround, CMF currently specifies the 'additional' Zope2 trunk
dependencies in buildout.cfg.
If there are no objections or better ideas, I'd like to add a
'zope212_compat' extra to Zope 2.12, 2.13 and trunk. For Zope 2.12 and
2.13 it would be empty, for trunk it would look like this:
extras_require={
'zope212_compat': [
'Products.BTreeFolder2',
'Products.ExternalMethod',
'Products.MailHost',
'Products.MIMETools',
'Products.PythonScripts',
'Products.StandardCacheManagers',
],
That would make it possible to specify the Zope2 dependency this way:
install_requires=[
'Zope2 [zope212_compat] = 2.12.15',
]
If Products drop Zope 2.12 support, they can switch to this:
install_requires=[
'Zope2 = 2.13.0',
'Products.MailHost', # required Products
You could release empty eggs for those folders. This is the approach
we are taking with the separation of Products.CMFPlone from the Plone
egg. This allows software to depend on ``Products.CMFPlone`` now but
still be compatible with Plone 4.0. See:
http://dev.plone.org/plone/browser/Products.CMFPlone/branches/4.0. (A
Products.CMFPlone=4.0 pin will be included the versions.cfg for the
next 4.0.x release.)
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
