Zope

Introduction RapidGiza is a set of paster templates for rapid Pyramid development. It makes several framework choices for the developer which are: Pyramid for the underlying web framework traversal based url routing Jinja2 for the page ... [More] template language (similar to Django templates) SQLAlchemy for ORM-based relational database persistence Important URL's Source Control - https://bitbucket.org/rockyburt/rapidgiza PyPi Entry - http://pypi.python.org/pypi/RapidGiza Setting up a New Project Install RapidGiza into a Python environment (ie virtualenv) with a working Paster. Once this has been done, you can create a new RapidGiza project by simply running (where Something is the name of your new egg): paster create -t rapidgiza Something Once the template egg has been created you should set it up in develop mode to start working on your project. cd Something python setup.py develop Using the New Project Command Runner By default a new script named something will be created in the bin directory of your python envionment. This script is a command runner that provides the following: Commands: runserver Run a reloadable development web server. Paster A development.ini file will be created inside the Something directory. This can be used with the standard paster commands: # use builtin paster http server paster serve development.ini # use the pyramid pshell command paster --plugin=pyramid pshell development.ini pyramid-Something Deployment with Apache+mod_wsgi There is a preconfigured Something.wsgi file generated which is necessary for plugging your app into a mod_wsgi environment. A simple apache virtualhost entry will look like this: ServerName www.something.com WSGIScriptAlias / /path/to/Something.wsgi Developing With the New Project Base Framework RapidGiza is based on the Pyramid web application framework. As such, the Pyramid api will always be the go-to api for working with the web application. Please see the Pyramid docs for further details. Templating Any file ending with the .jinja2 extension located inside the Something/something/templates directory will be rendered using the Jinja2 templating system. This template language is based on the Django templating language. RapidGiza produces two template files by default, one containing the overall layout called, layout.jinja2 and one for the default main page called, main.jinja2. Data Access All data access is handled by the SQLAlchemy ORM framework which wraps relational databases. Out of the box, any new project created by RapidGiza will have a SQLAlchemy database session factory setup. RapidGiza puts the orm model classes inside the models.py Python file. The active database session can always be retrieved as the db attribute on the request object. Transaction Support Transactions are used to ensure all or nothing is performed. With the very useful repoze.tm2 and transaction packages this can be accomplished easily in Pyramid applications. RapidGiza ensures all requests join a new transaction so that if any error/exception occurs, the transaction is automatically rolled back. Any db sessions created via the provided session factory automatically join this transaction and will be rolled back in the event an error occurs. Traversal The Pyramid web application framework provides a convenient mechanism to traverse an object graph and map that graph to url's. RapidGiza stores it's traversal mechanism inside of the traversal.py file. [Less]

zc.sourcefactory is very handy to easily create a source (zope.schema.interfaces.IIterableSource to be precise) with corresponding titles and tokens for its contents. Every now and then a source requires an explicit interface. For zc.sourcefactory ... [More] the following code snippet helps: class IMySource(zope.schema.interfaces.IIterableSource): """my source""" class MySource( zc.sourcefactory.contextual.BasicContextualSourceFactory): """The source factory.""" class source_class( zc.sourcefactory.source.FactoredContextualSource): """This class is being instanciated by the factory. It *must* be called source_class. """ zope.interface.implements(IMySource) def getValues(self, context): … Of course it is also possible to declare the source_class separately from the source factory and reference it. But since its sole purpose is to hold an implements declaration, I’m fine with defining it inline. [Less]

FLOSS Weekly (Free, Libre, Open Source Software) interviews Mark Ramm and I about the Pylons Project and the Pyramid web framework.

There is a issue that pops up from time to time, primarily with Python newbies on Stackoverflow.com and the like, but also with more experienced programmers.  And that is how to use package X that you installed for Python Y with Python Z. Sometimes ... [More] it is a library like PIL or NumPy, but quite often it’s pip or virtualenv and it’s associated scripts. And the answer is: You don’t! You install each library/module/package separately, once for each version of Python. The best way to do it is like this: You install each version of Python in a separate directory, like /opt/pythonXX, where XX is the version of Python, and /opt/pypy14 for PyPy, and so on. You download the script to install Distribute and run it, once for each version of Python you have installed. You will then get one easy_install script in each /opt/pythonXX/bin, so you run /opt/pythonXX/bin/easy_install virtualenv and optionally /opt/pythonXX/bin/easy_install pip for each version of Python. And that’s it. How do you then use this? Well: Now when you have a project that needs NumPy you make a project directory with the virtualenv of the Python you want to use for that project. Like so: /opt/python26/bin/virtualenv /my/projects/coolmaths Then you go to that directory: cd /my/projects/coolmaths Now you can, if you like, activate that virtualenv, but I never do that. Instead I just call the correct scripts explicitly like so ./bin/easy_install numpy Again, that’s it. It really is that simple. You install every Python separately, you install every module and package separately in those Python install, and you use everything explicitly. That solves all your problems. You can install all pythons in the same directory, like /usr/local, or /opt/pythons. This works well with python, and you then will have to chose which python by adding the version number to the executable: /usr/local/bin/python-2.4, for example. Distribute will work well with this too, you get /usr/local/bin/easy_install-2.7 etc. However, afaik can tell, pip does not always do this (maybe its’ a question of which pip version, or maybe it’s intelligent enough to know when it does have to? Not sure), so there you may have to make a copy of the pip script each time. But in any case, it’s much harder to delete and re-install a Python if you install them together like this. With separate directories you can, if your Python is fudged up, just remove the directory and do it again. Also: Avoid the system Python on OS X or Linux distros for your projects. You get stuck on a specific version, and you get conflicts with versions of packages, etc. The OS needs to have it’s versions, and you often needs others, and using the same Python install makes everything very complicated. So there. Now you know. Filed under: plone, python Tagged: distribute, pip [Less]

This is an escalation of privileges attack that can be used by anonymous users to gain access to a Plone site's administration controls, view unpublished content, create new content and modify a site's skin.  The sandbox protecting access to the ... [More] underlying system is still in place, and it does not grant access to other applications running on the same Zope instance. All versions of Plone since 2.5 are affected, viz. 2.5, 3.0, 3.1, 3.2, 3.3, 4.0; including all minor and development revisions of these versions.  Plone versions prior to 2.5, including Plone 1.0, Plone 2.0 and Plone 2.1 are not affected. The fix was released at 1621 UTC on Tuesday 8th February. Full installation instructions. Extra help Should you not have in-house server administrators or a service agreement looking after your website you can find consultancy companies on plone.net. There is also free support available online.   Previous Workaround Due to the nature of the vulnerability, the security team decided to pre-announce that a fix is upcoming before disclosing the details, to ensure that concerned users can plan around the release.  As the fix being published will make the details of the vulnerability public we are recommending that all users plan a maintenance window for 30 minutes either side of the announcement where your site is completely inaccessible in which to install the fix. We recommended to people that could not have a scheduled downtime that they take one of the following steps to protect their site from before the announcement until you apply the fix: Make your database read-only. Alternatively, if this option isn't possible due to not using one of our standard ZODB backends, disable logins by filtering HTTP authentication and cookies in Apache or Varnish. These did not need to be in place for the entire week but should already be in place before the fix and vulnerability details are released next week.  By preventing modifications to your site and patching your site quickly you remove the incentive for potential attackers to attempt this attack. Information for vulnerability database maintainers CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:T/RC:C) Impact Subscore 6.4 Exploitability Subscore 10 CVSS Temporal Score 6.4 Credit Alan Hoey Questions and Answers Q: When will the patch be made available? A: It is available now! The Plone Security Team released the patch at 16:21 GMT (11:21am US ET) on Tuesday February 8th, 2011. Q: How was this vulnerability found? A: This issue was found as part of a routine audit performed by the Plone Security team. Q: My site is highly visible and mission-critical. I hear the patch has already been developed. Can I get the fix before the release date? A: The Security Team has made the decision to not allow any early release of this patch so as to reduce the risks of exploitation. This decision applies to everyone, even Plone Foundation Members and Board members. Q: If the patch has been developed already, why isn't it already made available to the public? A: The Security Team is still testing the patch and running various scenarios thoroughly. The team is also making sure everybody has appropriate time to plan to patch their Plone installation(s). Some consultancy organizations have hundreds of sites to patch and need the extra time to coordinate their efforts with their clients. Q: How does one exploit the vulnerability? A: For obvious security reasons, the information will not be made available until after the patch is made available. Q: How can I be sure my website hasn't already been compromised? A: Yes, there is a script which will check your zope or apache log files for suspicious activity.  Download it then run it as: python logchecker.py /path/to/your/instance-Z2.log Q: Are there any third-party products I can use to protect my site until the patch is available? A: No. Q: I already applied version 1.0 of the hotfix to my site. Do I need to install version 1.1 now? A: You only need version 1.1 of the hotfix if you got exceptions when trying to use version 1.0. Version 1.1 fixes 2 minor installation edge cases but does not change the nature of the fix that is applied. [Less]

This is an escalation of privileges attack that can be used by anonymous users to gain access to a Plone site's administration controls, view unpublished content, create new content and modify a site's skin.  The sandbox protecting access to the ... [More] underlying system is still in place, and it does not grant access to other applications running on the same Zope instance. All versions of Plone since 2.5 are affected, viz. 2.5, 3.0, 3.1, 3.2, 3.3, 4.0; including all minor and development revisions of these versions.  Plone versions prior to 2.5, including Plone 1.0, Plone 2.0 and Plone 2.1 are not affected. Due to the severity of this issue we are providing an advance warning of an upcoming patch, which will be released on this page at 1600 GMT on Tuesday 8th February 2011. Workaround Due to the nature of the vulnerability, the security team has decided to pre-announce that a fix is upcoming before disclosing the details, to ensure that concerned users can plan around the release.  As the fix being published will make the details of the vulnerability public we are recommending that all users plan a maintenance window for 30 minutes either side of the announcement where your site is completely inaccessible in which to install the fix. If you cannot have this time offline we STRONGLY recommend that you take one of the following steps to protect your site from before the announcement until you apply the fix: Make your database read-only. Alternatively, if this option isn't possible due to not using one of our standard ZODB backends, disable logins by filtering HTTP authentication and cookies in Apache or Varnish. These do not need to be in place for the entire week but should already be in place before the fix and vulnerability details are released next week.  By preventing modifications to your site and patching your site quickly you remove the incentive for potential attackers to attempt this attack. Extra help Should you not have in-house server administrators or a service agreement looking after your website you can find consultancy companies on plone.net. There is also free support available online. Information for vulnerability database maintainers CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:T/RC:C) Impact Subscore 6.4 Exploitability Subscore 10 CVSS Temporal Score 6.4 Credit Alan Hoey Questions and Answers Q: When will the patch be made available? A: The Plone Security Team will release the patch at 16:00 GMT (11am US ET) on Tuesday February 8th, 2011. Q: How was this vulnerability found? A: This issue was found as part of a routine audit performed by the Plone Security team. Q: My site is highly visible and mission-critical. I hear the patch has already been developed. Can I get the fix before the release date? A: The Security Team has made the decision to not allow any early release of this patch so as to reduce the risks of exploitation. This decision applies to everyone, even Plone Foundation Members and Board members. Q: If the patch has been developed already, why isn't it already made available to the public? A: The Security Team is still testing the patch and running various scenarios thoroughly. The team is also making sure everybody has appropriate time to plan to patch their Plone installation(s). Some consultancy organizations have hundreds of sites to patch and need the extra time to coordinate their efforts with their clients. Q: How does one exploit the vulnerability? A: For obvious security reasons, the information will not be made available until after the patch is made available. Q: How can I be sure my website hasn't already been compromised? A: Unfortunately, there is no obvious or fool-proof way to know. Q: Are there any third-party products I can use to protect my site until the patch is available? A: Unfortunately, no. See below. Q: Is disabling access to certain paths, such as /login, enough to protect my site? A: The Plone Security team states that there are only 3 options to properly to protect your site: Disable authentication functionality (by filtering HTTP authentication and cookies in Apache or Varnish) Make your database read-only Take your website offline Q: Can I buy the Security Team a beer? A: Absolutely :-)   Steps to follow to apply the patch:   Check to confirm that the patch is applicable to the Plone version in place Remove access to authentication by following the information at: http://plone.org/documentation/kb/disable-logins-for-a-plone-site Restart/reload the webserver Wait for the patch to be released at http://plone.org/products/plone/security/advisories/cve-2011-0720 Back up the database Back up the buildout or instance code (Zope2  style install) For buildout-based installations: Verify that you have your various egg versions pinned (call a trained professional if you do not know what this means) Add the hotfix package to the instance eggs Re-run your buildout using bin/buildout -Nv For old style Zope installations: Place the hotfix into Zope's Products folder Restart the Zope instance(s) Reinstate authentication Restart/reload the web server Test Verify the site is back up Verify the patch was applied Verify authentication is back up Verify exploiting the vulnerability is no longer possible [Less]

This is an escalation of privileges attack that can be used by anonymous users to gain access to a Plone site's administration controls, view unpublished content, create new content and modify a site's skin.  The sandbox protecting access to the ... [More] underlying system is still in place, and it does not grant access to other applications running on the same Zope instance. All versions of Plone since 2.5 are affected, viz. 2.5, 3.0, 3.1, 3.2, 3.3, 4.0; including all minor and development revisions of these versions. Due to the severity of this issue we are providing an advance warning of an upcoming patch, which will be released on this page at 1600 GMT on Tuesday 8th February 2011. Workaround Due to the nature of the vulnerability, the security team has decided to pre-announce that a fix is upcoming before disclosing the details, to ensure that concerned users can plan around the release.  As the fix being published will make the details of the vulnerability public we are recommending that all users plan a maintenance window for 30 minutes either side of the announcement where your site is completely inaccessible in which to install the fix. If you cannot have this time offline we STRONGLY recommend that you take one of the following steps to protect your site from before the announcement until you apply the fix: Make your database read-only.Alternatively, if this option isn't possible due to not using one of our standard ZODB backends, disable logins by filtering HTTP authentication and cookies in Apache or Varnish. These do not need to be in place for the entire week but should already be in place before the fix and vulnerability details are released next week.  By preventing modifications to your site and patching your site quickly you remove the incentive for potential attackers to attempt this attack.    Extra help Should you not have in-house server administrators or a service agreement looking after your website you can find consultancy companies on plone.net.  There is also free support available online. Information for vulnerability database maintainers CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:T/RC:C) Impact Subscore 6.4 Exploitability Subscore 10 CVSS Temporal Score 6.4 Credit Alan Hoey [Less]

This is an escalation of privileges attack that can be used by anonymous users to gain access to a Plone site's administration controls, view unpublished content, create new content and modify a site's skin.  The sandbox protecting access to the ... [More] underlying system is still in place, and it does not grant access to other applications running on the same Zope instance. All versions of Plone since 2.5 are affected, viz. 2.5, 3.0, 3.1, 3.2, 3.3, 4.0; including all minor and development revisions of these versions. Due to the severity of this issue we are providing an advance warning of an upcoming patch, which will be released on this page at 1600 GMT on Tuesday 8th February 2011. Workaround Due to the nature of the vulnerability, the security team has decided to pre-announce that a fix is upcoming before disclosing the details, to ensure that concerned users can plan around the release.  As the fix being published will make the details of the vulnerability public we are recommending that all users plan a maintenance window for 30 minutes either side of the announcement where your site is completely inaccessible in which to install the fix. If you cannot have this time offline we STRONGLY recommend that you take one of the following steps to protect your site from before the announcement until you apply the fix: Make your database read-only. Alternatively, if this option isn't possible due to not using one of our standard ZODB backends, disable logins by filtering HTTP authentication and cookies in Apache or Varnish. These do not need to be in place for the entire week but should already be in place before the fix and vulnerability details are released next week.  By preventing modifications to your site and patching your site quickly you remove the incentive for potential attackers to attempt this attack. Extra help Should you not have in-house server administrators or a service agreement looking after your website you can find consultancy companies on plone.net. There is also free support available online. Information for vulnerability database maintainers CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:T/RC:C) Impact Subscore 6.4 Exploitability Subscore 10 CVSS Temporal Score 6.4 Credit Alan Hoey Questions and Answers Q: When will the patch be made available? A: The Plone Security Team will release the patch at 16:00 GMT (11am US ET) on Tuesday February 8th, 2011. Q: How was this vulnerability found? A: This issue was found as part of a routine audit performed by the Plone Security team. Q: My site is highly visible and mission-critical. I hear the patch has already been developed. Can I get the fix before the release date? A: The Security Team has made the decision to not allow any early release of this patch so as to reduce the risks of exploitation. This decision applies to everyone, even Plone Foundation Members and Board members. Q: If the patch has been developed already, why isn't it already made available to the public? A: The Security Team is still testing the patch and running various scenarios thoroughly. The team is also making sure everybody has appropriate time to plan to patch their Plone installation(s). Some consultancy organizations have hundreds of sites to patch and need the extra time to coordinate their efforts with their clients. Q: How does one exploit the vulnerability? A: For obvious security reasons, the information will not be made available until after the patch is made available. Q: How can I be sure my website hasn't already been compromised? A: Unfortunately, there is no obvious or fool-proof way to know. Q: Are there any third-party products I can use to protect my site until the patch is available? A: Unfortunately, no. See below. Q: Is disabling access to certain paths, such as /login, enough to protect my site? A: The Plone Security team states that there are only 3 options to properly to protect your site: Disable authentication functionality (by filtering HTTP authentication and cookies in Apache or Varnish) Make your database read-only Take your website offline Q: Can I buy the Security Team a beer? A: Absolutely :-) Steps to follow to apply the patch: Check to confirm that the patch is applicable to the Plone version in place Remove access to authentication by following the information at: http://plone.org/documentation/kb/disable-logins-for-a-plone-site Restart/reload the webserver Wait for the patch to be released at http://plone.org/products/plone/security/advisories/cve-2011-0720 Back up the database Back up the buildout or instance code (Zope2  style install) For buildout-based installations: Verify that you have your various egg versions pinned (call a trained professional if you do not know what this means) Add the hotfix package to the instance eggs Re-run your buildout using bin/buildout -Nv For old style Zope installations: Place the hotfix into Zope's Products folder Restart the Zope instance(s) Reinstate authentication Restart/reload the web server Test Verify the site is back up Verify the patch was applied Verify authentication is back up Verify exploiting the vulnerability is no longer possible [Less]

This is an escalation of privileges attack that can be used by anonymous users to gain access to a Plone site's administration controls, view unpublished content, create new content and modify a site's skin.  The sandbox protecting access to the ... [More] underlying system is still in place, and it does not grant access to other applications running on the same Zope instance. All versions of Plone since 2.5 are affected, viz. 2.5, 3.0, 3.1, 3.2, 3.3, 4.0; including all minor and development revisions of these versions.  Plone versions prior to 2.5, including Plone 1.0, Plone 2.0 and Plone 2.1 are not affected. Due to the severity of this issue we are providing an advance warning of an upcoming patch, which will be released on this page at 1600 GMT on Tuesday 8th February 2011. Workaround Due to the nature of the vulnerability, the security team has decided to pre-announce that a fix is upcoming before disclosing the details, to ensure that concerned users can plan around the release.  As the fix being published will make the details of the vulnerability public we are recommending that all users plan a maintenance window for 30 minutes either side of the announcement where your site is completely inaccessible in which to install the fix. If you cannot have this time offline we STRONGLY recommend that you take one of the following steps to protect your site from before the announcement until you apply the fix: Make your database read-only. Alternatively, if this option isn't possible due to not using one of our standard ZODB backends, disable logins by filtering HTTP authentication and cookies in Apache or Varnish. These do not need to be in place for the entire week but should already be in place before the fix and vulnerability details are released next week.  By preventing modifications to your site and patching your site quickly you remove the incentive for potential attackers to attempt this attack. Extra help Should you not have in-house server administrators or a service agreement looking after your website you can find consultancy companies on plone.net. There is also free support available online. Information for vulnerability database maintainers CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P/E:F/RL:T/RC:C) Impact Subscore 6.4 Exploitability Subscore 10 CVSS Temporal Score 6.4 Credit Alan Hoey Questions and Answers Q: When will the patch be made available? A: The Plone Security Team will release the patch at 16:00 GMT (11am US ET) on Tuesday February 8th, 2011. Q: How was this vulnerability found? A: This issue was found as part of a routine audit performed by the Plone Security team. Q: My site is highly visible and mission-critical. I hear the patch has already been developed. Can I get the fix before the release date? A: The Security Team has made the decision to not allow any early release of this patch so as to reduce the risks of exploitation. This decision applies to everyone, even Plone Foundation Members and Board members. Q: If the patch has been developed already, why isn't it already made available to the public? A: The Security Team is still testing the patch and running various scenarios thoroughly. The team is also making sure everybody has appropriate time to plan to patch their Plone installation(s). Some consultancy organizations have hundreds of sites to patch and need the extra time to coordinate their efforts with their clients. Q: How does one exploit the vulnerability? A: For obvious security reasons, the information will not be made available until after the patch is made available. Q: How can I be sure my website hasn't already been compromised? A: Unfortunately, there is no obvious or fool-proof way to know. Q: Are there any third-party products I can use to protect my site until the patch is available? A: Unfortunately, no. See below. Q: Is disabling access to certain paths, such as /login, enough to protect my site? A: The Plone Security team states that there are only 3 options to properly to protect your site: Disable authentication functionality (by filtering HTTP authentication and cookies in Apache or Varnish) Make your database read-only Take your website offline Q: Can I buy the Security Team a beer? A: Absolutely :-)   Steps to follow to apply the patch:   Check to confirm that the patch is applicable to the Plone version in place Remove access to authentication by following the information at: http://plone.org/documentation/kb/disable-logins-for-a-plone-site Restart/reload the webserver Wait for the patch to be released at http://plone.org/products/plone/security/advisories/cve-2011-0720 Back up the database Back up the buildout or instance code (Zope2  style install) For buildout-based installations: Verify that you have your various egg versions pinned (call a trained professional if you do not know what this means) Add the hotfix package to the instance eggs Re-run your buildout using bin/buildout -Nv For old style Zope installations: Place the hotfix into Zope's Products folder Restart the Zope instance(s) Reinstate authentication Restart/reload the web server Test Verify the site is back up Verify the patch was applied Verify authentication is back up Verify exploiting the vulnerability is no longer possible [Less]

Last wednesday I finished a website that's been brewing for a while. http://www.bijbelvereniging.nl . I'm quite happy with it! On 2007-07-25, I made the initial svn import of the existing website of the bijbelvereniging, a Dutch group ... [More] that was formerly a member of Gideons international. (There are now two Gideon(-like) groups in the Netherlands, one handing out bibles in public and one placing bibles in hotels/hospitals/jails: the latter one is the bijbelvereniging.) The old site was a (to me) horrid frame-using websites. More than 10 years old, probably. Frames! I always avoided them like the plague. The html code was horrible. Probably fine in the day when it was made, but... Visually, the site looked fine, btw. Anyway, the site was to be replaced in the near future. In the end, the replacement process dragged on until around early 2010. Ideas floated around and I got a couple of examples of the new default layout they were using for brochures and paperware. For the implementation, I chose wordpress, though I made an initial prototype in Plone. Reasons? I might want to hand the site over to someone else for maintenance: wordpress knowledge is easier to find than Plone knowledge. (Plone is what I'd have used otherwise). Small site, so nothing elaborate is needed. I had some recent experience (http://www.ngk.nl) with a wordpress website and wordpress wasn't too bad. They wanted it hosted on a regular hosting party, so Plone was pretty much out (I offered to host it on my own server, though, but they stuck to their existing hoster). What I did? I made the layout. Blueprint css framework plus a bit of jquery for the menu, that's basically it. And a bit of "gimp" image editing for the backgrounds and the header. A wordpress theme so I had a cleanly installable nicely-separated collection of php and css that makes up the actual website. Added a couple of forms and build up the menu structure. The actual text and part of the menu? The other images? That's what "the customer" did, in this case two people from the bijbelvereniging. It was a requirement that they'd be able to change things on their own without having to mail me. Rightfully so. That's something that should be standard for most sites nowadays. [Less]