5 ms·

WSGI Middleware Considered Harmful

17 points by joubert 16y ago

joubert 16y ago
this was written early 2007. do you guys / girls agree with the author?
- stevenwei 16y ago
  I still agree. Middleware can be effective for certain cross cutting situations (csrf checking and database transaction handling come to mind), but I think it's been applied to too many problems where it was completely unnecessary. For example, user authentication in most web apps needs to be dealt with at the application level. Middleware based approaches like AuthKit and repoze.who end up relying on weird hacks to communicate between the authentication middleware and the application layer.I'm really not a fan of shuffling important application level data through random environment variables. Not to mention they're a massive pain in the ass to configure. Note that for both csrf checking and database transaction handling, you still need hooks in place at your application level to be able to disable csrf checks or transactions in certain application specific situations, so it's not like you can just throw it into the middleware layer and forget about it.
  - zepolen 16y ago
    > you still need hooks in place at your application level to be able to disable csrf checks Why would you want to disable the csrf check?
    - stevelosh 16y ago
      One example: for AJAX requests. From http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax Most modern JavaScript toolkits send an "X-Requested-With: XMLHttpRequest" HTTP header; these requests are detected and automatically not handled by this [CSRF] middleware. We can do this safely because, in the context of a browser, the header can only be added by using XMLHttpRequest, and browsers already implement a same-domain policy for XMLHttpRequest.
      - zepolen 16y ago
        Fair enough, but it doesn't mean your app requires hooks since the middleware can just not use CSRF if the x-requested-with header exists.
  - joubert 16y ago
    Do you have a recommended session-handling API for a WSGI-based app (I'm not a framework such as Django)? I'm currently looking at Beaker (http://beaker.groovie.org/index.html http://beaker.groovie.org/index.html) but it is a middleware-based approach.
    - stevenwei 16y ago
      I think Beaker has been the Python standard for a while now (at least in non Django land). I would also recommend checking out Werkzeug in general, although its scope is a bit different than Beaker.
spooneybarger 16y ago
I haven't done anything other than dabble with python in years and have never used WSGI, can someone point me to examples of this 'abuse' of WSGI in the wild? I'd love to get more background so I can really understand this post.
- joubert 16y ago
  the author's argument is essentially that you shouldn't reach out to middleware from within your application code (e.g. sessions), but that such functionality should be provided by a non-middleware API, because you should be able to swap in/out middleware without any change to your app code.
  - spooneybarger 16y ago
    are there examples of WSGI applications that provide sessions as middleware? just curious to see the approach in action.
    - joubert 16y ago
      I found Beaker, which looks pretty nice. http://beaker.groovie.org/index.html http://beaker.groovie.org/index.html
zepolen 16y ago
Imho there is Pure and Unpure WSGI middleware, the former can be used or removed with zero change to the application, this works for things like: - profiling - caching - csrf protection This is what I think wsgi middleware should be.
jrockway 16y ago
Excellent rant. I have noticed the exact same problems with PSGI middleware. People end up with apps that depend on middleware that then depend on the app. This serves two purposes: making for a nice blog post about how generic you are (just implement these eight functions inside your app!), and adding bugs. Just treat web programming like normal programming, and everything becomes simple!

17 points by joubert 16y ago

joubert 16y ago

this was written early 2007. do you guys / girls agree with the author?

stevenwei 16y ago
I still agree. Middleware can be effective for certain cross cutting situations (csrf checking and database transaction handling come to mind), but I think it's been applied to too many problems where it was completely unnecessary. For example, user authentication in most web apps needs to be dealt with at the application level. Middleware based approaches like AuthKit and repoze.who end up relying on weird hacks to communicate between the authentication middleware and the application layer.I'm really not a fan of shuffling important application level data through random environment variables. Not to mention they're a massive pain in the ass to configure. Note that for both csrf checking and database transaction handling, you still need hooks in place at your application level to be able to disable csrf checks or transactions in certain application specific situations, so it's not like you can just throw it into the middleware layer and forget about it.
- zepolen 16y ago
  > you still need hooks in place at your application level to be able to disable csrf checks Why would you want to disable the csrf check?
  - stevelosh 16y ago
    One example: for AJAX requests. From http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax Most modern JavaScript toolkits send an "X-Requested-With: XMLHttpRequest" HTTP header; these requests are detected and automatically not handled by this [CSRF] middleware. We can do this safely because, in the context of a browser, the header can only be added by using XMLHttpRequest, and browsers already implement a same-domain policy for XMLHttpRequest.
    - zepolen 16y ago
      Fair enough, but it doesn't mean your app requires hooks since the middleware can just not use CSRF if the x-requested-with header exists.
- joubert 16y ago
  Do you have a recommended session-handling API for a WSGI-based app (I'm not a framework such as Django)? I'm currently looking at Beaker (http://beaker.groovie.org/index.html http://beaker.groovie.org/index.html) but it is a middleware-based approach.
  - stevenwei 16y ago
    I think Beaker has been the Python standard for a while now (at least in non Django land). I would also recommend checking out Werkzeug in general, although its scope is a bit different than Beaker.

spooneybarger 16y ago

I haven't done anything other than dabble with python in years and have never used WSGI, can someone point me to examples of this 'abuse' of WSGI in the wild? I'd love to get more background so I can really understand this post.

joubert 16y ago
the author's argument is essentially that you shouldn't reach out to middleware from within your application code (e.g. sessions), but that such functionality should be provided by a non-middleware API, because you should be able to swap in/out middleware without any change to your app code.
- spooneybarger 16y ago
  are there examples of WSGI applications that provide sessions as middleware? just curious to see the approach in action.
  - joubert 16y ago
    I found Beaker, which looks pretty nice. http://beaker.groovie.org/index.html http://beaker.groovie.org/index.html

zepolen 16y ago

Imho there is Pure and Unpure WSGI middleware, the former can be used or removed with zero change to the application, this works for things like: - profiling - caching - csrf protection This is what I think wsgi middleware should be.

jrockway 16y ago

Excellent rant. I have noticed the exact same problems with PSGI middleware. People end up with apps that depend on middleware that then depend on the app. This serves two purposes: making for a nice blog post about how generic you are (just implement these eight functions inside your app!), and adding bugs. Just treat web programming like normal programming, and everything becomes simple!