From a39aca5c464d275d0d5d9654fe70b63b7e92f41e Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Wed, 28 Jul 2010 16:34:18 +0000 Subject: - Added a section named "Zope 3 Enforces 'TTW' Authorization Checks By Default; BFG Does Not" to the "Design Defense" chapter. --- CHANGES.txt | 3 +++ docs/designdefense.rst | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+) diff --git a/CHANGES.txt b/CHANGES.txt index e0a0771c7..2daba6f4d 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -32,6 +32,9 @@ Documentation - Added ``repoze.bfg.events.subscriber`` API documentation to ``repoze.bfg.events`` API docs. +- Added a section named "Zope 3 Enforces 'TTW' Authorization Checks By + Default; BFG Does Not" to the "Design Defense" chapter. + 1.3a6 (2010-07-25) ================== diff --git a/docs/designdefense.rst b/docs/designdefense.rst index 6962b02d7..09b1a1bba 100644 --- a/docs/designdefense.rst +++ b/docs/designdefense.rst @@ -1139,6 +1139,64 @@ This means it's not yet possible to declaratively deprecate the older non-core package in the eyes of tools like ``easy_install``, ``pip`` and ``buildout``. +Zope 3 Enforces "TTW" Authorization Checks By Default; BFG Does Not +------------------------------------------------------------------- + +Challenge +~~~~~~~~~ + +:mod:`repoze.bfg` performs automatic authorization checks only at +:term:`view` execution time. Zope 3 wraps context objects with a +`security proxy `, +which causes Zope 3 to do also security checks during attribute +access. I like this, because it means: + +#) When I use the security proxy machinery, I can have a view that + conditionally displays certain HTML elements (like form fields) or + prevents certain attributes from being modified depending on the + depending on the permissions that the accessing user possesses with + respect to a context object. + +#) I want to also expose my model via a REST API using Twisted Web. If + If BFG perform authorization based on attribute access via Zope3's + security proies, I could enforce my authorization policy in both + :mod:`repoze.bfg` and in the Twisted-based system the same way. + +Defense +~~~~~~~ + +:mod:`repoze.bfg` was developed by folks familiar with Zope2, which +has a "through the web" security model. The TTW security model which +was the precursor to Zope 3's security proxies. Over time, as the +:mod:`repoze.bfg` developers (working in Zope2) created such sites, we +found authorization checks during code interpretation extremely useful +in a minority of projects. But much of the time, TTW authorization +checks usually slowed down the development velocity of projects that +had no delegation requirements. In particular, if we weren't allowing +"untrusted" users to write arbitrary Python code to be executed by our +application, the burden of "through the web" security checks proved +too costly to justify. We (collectively) haven't written an +application on top of which untrusted developers are allowed to write +code in many years, so it seemed to make sense to drop this model by +default in a new web framework. + +And since we tend to use the same toolkit for all web applications, it's +just never been a concern to be able to use the same set of +restricted-execution code under two web different frameworks. + +The original author justifications for disabling security proxies by +default notwithstanding, given that Zope 3 security proxies are +"viral" by nature, the only requirement to use one is to make sure you +wrap a single object in a security proxy and make sure to access that +object normally when you want proxy security checks to happen. It is +possible to override the :mod:`repoze.bfg` "traverser" for a given +application (see :ref:`changing_the_traverser`). It is possible to +plug in a different traverser which returns +Zope3-security-proxy-wrapped objects for each traversed object +(including the :term:`context` and the :term:`root`). This would have +the effect of creating a more Zope3-like environment without much +effort. + Other Challenges ---------------- -- cgit v1.2.3