collective.diazo.readheaders 0.1

Introduction

“What’s Diazo?”, I hear you say. From diazo.org:

Diazo allows you to apply a theme contained in a static HTML web page to a dynamic website created using any server-side technology. With Diazo, you can take an HTML wireframe created by a web designer and turn it into a theme for your favourite CMS, redesign the user interface of a legacy web application without even having access to the original source code, or build a unified user experience across multiple disparate systems, all in a matter of hours, not weeks.

When using Diazo, you will work with syntax and concepts familiar from working with HTML and CSS. And by allowing you seamlessly integrate XSLT into your rule files, Diazo makes common cases simple and complex requirements possible.

About this package

This package extends the standard theming middleware of Diazo to add the ability to read the location of a rules XML file from the WSGI environment. This means, amongst being able to read a rules location from the environment for the local user, that an upstream service (such as a web server, reverse proxy, caching proxy, etc) is able to control the theme the middleware is using – and change this for any given request. This contrasts with the configuration-based approach taken by Diazo’s standard middleware, which requires a fixed path to be specified for the middleware.

So, this means with the right WSGI configuration, you could conceivably have one Diazo instance serving any number of themes without needing to explicitly configure paths, urlmaps or the like. If you combine this with a suitable front-facing tool (such as a configurable web server like Apache, Nginx, Cherokee, or any other), then you can have this one Diazo instance theming any number of applications, and theming differently based upon any condition your web server supports – such as incoming host name, HTTP vs HTTPS, specific URLs or regex, headers, IP addresses, and more. To achieve this, all you need to do is set the right HTTP header – which is the path to your rules file – and ensure this is sent to your middleware based upon your various conditions.

Example

In this example, we can deploy this extended Diazo middleware to act as a one-size-fits-all theming backend behind our web server. With the right WSGI pipeline, we can have one WSGI pipeline servicing as many backends as you like, serving any number of different themes, all without any explicit WSGI configuration. Keep in mind the potential of header spoofing - exercise extreme care.

[server:main]
use = egg:Paste#http
host = 0.0.0.0
port = 5000

[composite:main]
use = egg:Paste#urlmap
/ = default

[pipeline:default]
pipeline = theme
           proxy

[filter:theme]
use = egg:collective.diazo.readheaders
#You can use any other Diazo middleware options here, too!
read_network = True
debug = True

[app:proxy]
use = egg:djb.headerproxy

RequestHeader set "X-Diazo-Rules" "/path/to/rules.xml"
RequestHeader set "X-Proxy-Force-Host" "app-server.example.com:8080"
RequestHeader set "X-Proxy-Force-Scheme" "http"
RewriteRule / http://localhost:5000 [L,P]

RequestHeader set X-Diazo-Rules "http://example.com/path/to/rules.xml"

[uwsgi]
home = /opt/diazo
processes = 8
vacuum = true
master = true
socket = %(home)/var/uwsgi.sock
pythonpath = %(home)/eggs/*.egg
pythonpath = %(home)/src/*

cd /opt/diazo
virtualenv .
source bin/activate
pip install uwsgi collective.diazo.readheaders djb.headerproxy

./bin/uwsgi --ini-paste diazo.ini

[buildout]
parts = lxml instance
eggs-directory = eggs

[lxml]
recipe = z3c.recipe.staticlxml
egg = lxml

[instance]
recipe = zc.recipe.egg
eggs =
    collective.diazo.readheaders
    djb.headerproxy
    uwsgi
dependent-scripts = true

Contributing

Join in at https://github.com/collective/collective.diazo.readheaders – if you’re already a member of the Collective then you can already push changes. Otherwise, fork away and send a pull request.

Contributors

David Beitey, Author

Changelog

0.1 (2012-08-09)

• Package created using templer [David Beitey]