I've been experimenting lately with repoze.tm2 and integrating it into a
CRUD app generator I'm writing as a google summer of code project for
turbogears. This app can run standalone but should also be easy to mount
inside a Turbogears 2 app (or any WSGI stack). I'd like to use repoze.tm2
for the later cases so both apps can share a transaction boundary.

However, one think that has struck me is that repoze.tm's middleware 
doesn't check the status code of the WSGI response and blindly commits if
no exception has occurred. This will cause errors if, for example, an
authorization middleware is stacked below (closer to the app) reopze.tm
which converts some sort of SecurityException into 403 HTTP responses
since repoze.tm will commit the transaction even though an error has
ocurred (effectively circumventing the app's security policy). In fact,
this exact example has bitten me in a production app (that's why I'm so

I know this can be fixed by placing this imaginary auth middleware above
repoze.tm in the stack but perhaps the auth middleware also needs to
participate in the transaction (if it needs a database to lookup users,
for example).

Since I had to set up a demo of my project today
(http://rumdemo.toscawidgets.org in case anyone's interested) I ended up
copying the tm middleware and applying the "fix" locally [1] but this
suboptimal since TG2 will no longer be able to share transactions with
Rum, unless we release a modified version as a separate egg we can both
depend on, effectively forking repoze.tm2 for no good reason.

So,is this really an issue for you guys? Any plans to implement a similar
"fix" (mine requires WebOb but it can be easily rewritten without it, I'm
happy to contribute something)? Am I overlooking something obvious which
makes all this a moot issue?


[1] http://toscawidgets.org/trac/rum/browser/rum/middleware.py#L9

BTW, Any plans to register repoze.tm2 at PyPI?

Repoze-dev mailing list

Reply via email to