progressive enhancement using wsgi
DESCRIPTION
TRANSCRIPT
Matthew Wilkes
Progressive enhancement using WSGI
/ˈwɪski/A Python API for web applications
Matthew Wilkes
• Zope / Plone core developer.
• Performance and Security work at the Code Distillery
• WSGI/Whisky snob.
• Developed large applications using WSGI.
• Co-author of the Zope’s WSGI support.
WSGI apps
Just an API for handling HTTP requests. Used by:
• Pyramid
• Zope
• CherryPy
• Web2Py
• … most people
Composites
Composites join multiple WSGI apps together
• Subsite URL Routing
• Management screens
Middlewares
Middlewares are used for changing a webapp’s input/output
• Theming/Design
• Error handling
• Adding features
• URL rewriting
• Embargos of information
Mistakes…
Python specific
• “Middlewares are easier to write than normal libraries”
• Cannot assume that you won’t want to use it on a PHP app in future
• Proxies allow heterogenous applications to be composed
• Being language agnostic doesn’t mean you will have to write Perl code (it helps you avoid it)
A waste of time
• Simple modifications work best as middlewares
• But, simple modifications are easy in your framework
• “I should just fix it in place”
• “This wouldn’t be useful to other people, so I’ll leave it in the customer project”
• You’ll likely make another website sometime soon
The Good bits
Great libraries
• WebOb makes requests easy to deal with.
• The wsgiref WSGI web server is in the Standard Library
• Lots of other server frontends to select for production
• Paste’s Transparent Proxy lets you test the middleware on any website
• lxml makes managing HTML easy
• PasteDeploy provides .ini app composition
Templates
• http://pypi.python.org/pypi/wsgitemplates
• http://pythonpaste.org/deploy/#the-config-file
• http://docs.webob.org/en/latest/wiki-example.html
But… you said progressive enhancement
CAPTCHAs
• Many ways to do them in Plone
• Archetypes, formlib, z3c.form, custom view, plone.app.discussion, PloneFormGen, …
• Some code reuse
• Not enough
• So, middleware?
CAPTCHAs
• If we’re building a new application we have the most flexibility.
• We want a boolean, isHuman.
• Simplest CAPTCHA possible is a checkbox.(Hey! No lying, Spambots!)
• So, add that with your favourite form library.
CAPTCHAs
• Not a very effective CAPTCHA.
• But, many historical CAPTCHAs are now unusable…
• As the enemy is getting better, too.
• Need to decouple the logic of ‘test for human’ and the method.
• Use a WSGI Middleware to rewrite the form.
The code
• The middleware extracts the checkboxes from the application as requests are served.
• CAPTCHAs are generated and the image inserted.
• The valid responses are stored in memory.
• Inbound requests check the input and emulate selecting the checkbox.
CAPTCHAs
• A small Python class will now work on any web-app backend.
• If you happen to have another application that also outputs the checkboxes, this will slot right in front
• But… you don’t really want to be adding checkboxes to the legacy apps.
• So, middleware?
The code
• The middleware detects <form>s as requests are served.
• The checkbox is inserted
• Inbound requests check if the checkbox is selected
• If not, redirect back with form data in GET
• Otherwise, remove the checkbox value and POST on.
Overkill?
Maybe.
• Performance damage is very low.
• Decide on the what will save you the most development time in the long-term.
• Need more initial effort for the middleware
• But all your deployments that use it can do so without the ‘upgrade the customer site to the latest trunk’ tax that stops you right now.
• And it can be open sourced, so others will help you add features.
Links
https://github.com/MatthewWilkes/islay.simplecaptcha
https://github.com/MatthewWilkes/islay.hardercaptcha
