{ "info": { "author": "David Beitey", "author_email": "python@davidjb.com", "bugtrack_url": null, "classifiers": [ "Programming Language :: Python" ], "description": ".. contents::\n\nIntroduction\n============\n\n\"What's Diazo?\", I hear you say. From `diazo.org `_:\n\n Diazo allows you to apply a theme contained in a static HTML web page to a\n dynamic website created using any server-side technology. With Diazo, you\n can take an HTML wireframe created by a web designer and turn it into a\n theme for your favourite CMS, redesign the user interface of a legacy web\n application without even having access to the original source code, or\n build a unified user experience across multiple disparate systems, all in a\n matter of hours, not weeks.\n\n When using Diazo, you will work with syntax and concepts familiar from\n working with HTML and CSS. And by allowing you seamlessly integrate XSLT\n into your rule files, Diazo makes common cases simple and complex\n requirements possible.\n\nAbout this package\n==================\n\nThis package extends the standard theming middleware of Diazo to add the\nability to read the location of a rules XML file from the WSGI environment.\nThis means, amongst being able to read a rules location from the environment\nfor the local user, that an upstream service (such as a web server, reverse\nproxy, caching proxy, etc) is able to control the theme the middleware is using\n-- and change this for any given request. This contrasts with the\nconfiguration-based approach taken by Diazo's standard middleware, which\nrequires a fixed path to be specified for the middleware.\n\nSo, this means with the right WSGI configuration, you could conceivably have\none Diazo instance serving any number of themes without needing to explicitly\nconfigure paths, urlmaps or the like. If you combine this with a suitable\nfront-facing tool (such as a configurable web server like Apache, Nginx,\nCherokee, or any other), then you can have this one Diazo instance theming any\nnumber of applications, and theming differently based upon any condition your\nweb server supports -- such as incoming host name, HTTP vs HTTPS, specific URLs\nor regex, headers, IP addresses, and more. To achieve this, all you need to do\nis set the right HTTP header -- which is the path to your rules file -- and\nensure this is sent to your middleware based upon your various conditions.\n\nExample\n=======\n\nIn this example, we can deploy this extended Diazo middleware to act as a\none-size-fits-all theming backend behind our web server. With the right\nWSGI pipeline, we can have one WSGI pipeline servicing as many backends \nas you like, serving any number of different themes, all without any explicit\nWSGI configuration. Keep in mind the potential of header spoofing - exercise\nextreme care.\n\nWSGI pipeline\n-------------\n\nPrepare a configuration for PasteScript as follows::\n\n [server:main]\n use = egg:Paste#http\n host = 0.0.0.0\n port = 5000\n\n [composite:main]\n use = egg:Paste#urlmap\n / = default\n\n [pipeline:default]\n pipeline = theme\n proxy\n\n [filter:theme]\n use = egg:collective.diazo.readheaders\n #You can use any other Diazo middleware options here, too!\n read_network = True\n debug = True\n\n [app:proxy]\n use = egg:djb.headerproxy\n\nOver the standard Diazo/WSGI configuration seen at\nhttp://docs.diazo.org/en/latest/quickstart.html keen-eyed viewers will notice\nthe following:\n\n#. We use ``collective.diazo.readheaders`` instead of ``diazo`` - this\n allows the ``X-Diazo-Rules`` header to be read from the incoming WSGI\n environment and used as the traditional ``rules`` option. This means\n that any format the ``rules`` option accepts (such as network-based URLs)\n will work if set as this header. In the specific case of network URLs, you\n will need to configure ``read_network`` to be enabled.\n \n This section automatically accepts any and add options that Diazo does: see\n http://docs.diazo.org/en/latest/deployment.html#wsgi - and we demonstrate\n this above. \n\n#. We use the special WSGI proxy `djb.headerproxy\n `_ which will reverse proxy to\n an arbitrary location based upon incoming headers. By comparison, the\n standard Paste proxy requires an explicitly defined address in the\n configuration. As per the documentation for ``djb.headerproxy``, the headers\n upstream are, by default, expected to be ``X-Proxy-Force-Host`` and \n ``X-Proxy-Force-Scheme`` -- this mapping is configurable, however.\n\nFront-end\n---------\n\nNow, in our front-end server, we can configure our reverse proxy and\nset the headers accordingly. For instance, with Apache you might do the\nfollowing::\n\n RequestHeader set \"X-Diazo-Rules\" \"/path/to/rules.xml\"\n RequestHeader set \"X-Proxy-Force-Host\" \"app-server.example.com:8080\"\n RequestHeader set \"X-Proxy-Force-Scheme\" \"http\"\n RewriteRule / http://localhost:5000 [L,P]\n\nIn which, the rewrite rule points to the location of the service running\nthe above Paste WSGI configuration. \n\nDon't forget that the ``X-Diazo-Rules`` option will be interpreted on the\nlocal machine running the WSGI pipeline. So, if you refer to a local file\nit will be local to *that machine*. This point is moot if you are running\nDiazo on the same machine - but it should still be emphasised. Keep in \nmind too that you can configure options like this::\n\n RequestHeader set X-Diazo-Rules \"http://example.com/path/to/rules.xml\"\n\nand they will work as well (assuming, at least in this case, that your\nmiddleware has the ``read_network`` option enabled).\n\nDeployment options\n^^^^^^^^^^^^^^^^^^\n\nYou can deploy using your choice of server -- it doesn't need to be Paste.\nSimilarly, you can deploy with your choice of front-end -- it certainly doesn't\nneed to be Apache. If you've deployed something similar to the above, then\nconsider contributing your deployment configuration here!\n\nCherokee, uWSGI and Pip/Buildout\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOne successful deployment utilises the `Cherokee web server\n`_ and `uWSGI `_\nand runs uWSGI using a local socket on the web server machine. Cherokee (much\nlike Ngnix) can talk directly to uWSGI, which in turn is able to directly\nutilise Paste-style ini configuration, like the one above. For uWSGI, the only\naddition configuration needed was to add this to the top of the ini file::\n\n [uwsgi]\n home = /opt/diazo\n processes = 8\n vacuum = true\n master = true\n socket = %(home)/var/uwsgi.sock\n pythonpath = %(home)/eggs/*.egg\n pythonpath = %(home)/src/*\n\nand then uWSGI, which was simply installed along with all dependencies thus::\n\n cd /opt/diazo\n virtualenv .\n source bin/activate\n pip install uwsgi collective.diazo.readheaders djb.headerproxy\n\ncan be easily started using::\n\n ./bin/uwsgi --ini-paste diazo.ini\n\nwhich reads its own options from the configuration, together with the WSGI\npipeline and associated config. For bonus points, you can also deploy the\nabove with `Buildout `_ too::\n\n [buildout]\n parts = lxml instance\n eggs-directory = eggs\n\n [lxml]\n recipe = z3c.recipe.staticlxml\n egg = lxml\n\n [instance]\n recipe = zc.recipe.egg\n eggs =\n collective.diazo.readheaders\n djb.headerproxy\n uwsgi\n dependent-scripts = true\n\nPhew!\n\nContributing\n============\n\nJoin in at https://github.com/collective/collective.diazo.readheaders --\nif you're already a member of the Collective then you can already push changes.\nOtherwise, fork away and send a pull request.\n\nContributors\n============\n\nDavid Beitey, Author\n\nChangelog\n=========\n\n0.1 (2012-08-09)\n----------------\n\n- Package created using templer\n [David Beitey]", "description_content_type": null, "docs_url": null, "download_url": "UNKNOWN", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/collective/collective.diazo.readheaders", "keywords": "diazo theme wsgi html xslt", "license": "gpl", "maintainer": null, "maintainer_email": null, "name": "collective.diazo.readheaders", "package_url": "https://pypi.org/project/collective.diazo.readheaders/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/collective.diazo.readheaders/", "project_urls": { "Download": "UNKNOWN", "Homepage": "https://github.com/collective/collective.diazo.readheaders" }, "release_url": "https://pypi.org/project/collective.diazo.readheaders/0.1/", "requires_dist": null, "requires_python": null, "summary": "Middleware that allows flexible Diazo theme selection based upon incoming HTTP headers. Extends functionality found in Diazo.", "version": "0.1" }, "last_serial": 721936, "releases": { "0.1": [ { "comment_text": "", "digests": { "md5": "603178e12a5ebd81aa1c0c330e8360de", "sha256": "2950c133e509ef43e28253a208633a4df9b3dd5a6de07938697c7bed941ac171" }, "downloads": -1, "filename": "collective.diazo.readheaders-0.1.zip", "has_sig": false, "md5_digest": "603178e12a5ebd81aa1c0c330e8360de", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 23470, "upload_time": "2012-08-09T03:30:07", "url": "https://files.pythonhosted.org/packages/ea/21/6fa06803a0a73b6ec4da6e79639deb25ec0b3efd9e9616d08fe8b4686b5b/collective.diazo.readheaders-0.1.zip" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "603178e12a5ebd81aa1c0c330e8360de", "sha256": "2950c133e509ef43e28253a208633a4df9b3dd5a6de07938697c7bed941ac171" }, "downloads": -1, "filename": "collective.diazo.readheaders-0.1.zip", "has_sig": false, "md5_digest": "603178e12a5ebd81aa1c0c330e8360de", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 23470, "upload_time": "2012-08-09T03:30:07", "url": "https://files.pythonhosted.org/packages/ea/21/6fa06803a0a73b6ec4da6e79639deb25ec0b3efd9e9616d08fe8b4686b5b/collective.diazo.readheaders-0.1.zip" } ] }