This project has been archived by its maintainers, and is no longer receiving any updates.
Django Birdcage
When deploying large websites, operations teams will sometimes deploy new code across a subset of the entire collection of webservers. This approach is called a “Canary” deployment. Most users will continue to be served using the old code; only those users hitting a “Canary” machine will see the new code.
Large websites will often use a Canary when the perceived risk of an upgrade is high. For example, upgrading the Django version from 1.8 LTS to 1.11 LTS on a complex site will generally be considered a risky upgrade; a Canary will be used to test that the upgrade is working as expected before switching all webservers over to the upgraded codebase.
Unfortunately, while Django has good backwards compatibility guarantees, Canary deployments require forwards compatibility as well. This is beacuse a user may have one request served on the new codebase, but subsequent updates served from the old codebase. If information (such as security tokens) aren’t both backwards and forwards compatible between releases, some users will see errors as the move back and forth between old and new codebases.
Birdcage is a project consisting of tools to help you manage Canary upgrades, by provided forwards compatible shims for known problems in Django.
What does Birdcage address?
Django 1.10: Salted CSRF tokens
Django 1.10 introduced a change to CSRF handling to protect against BREACH attacks. Django 1.10+ can interpret Django < 1.10 CSRF tokens; however, if a user is issued a Django 1.10+ CSRF token, it will be rejected as invalid by Django 1.8.
To address this problem, Birdcage provides a version of Django 1.8’s CsrfViewMiddleware that can interpret Django 1.10’s CSRF tokens.
In the settings for your Django 1.8 codebase, replace django.middleware.csrf.CsrfViewMiddleware in your MIDDLEWARE setting with birdcage.v1_11.csrf.CsrfViewMiddleware.
In your Django 1.10+ codebase, continue to use the Django CsrfViewMiddleware.
Why is it called Birdcage?
Well you have to put your canaries somewhere to keep them safe… :-)
1 maintainer
Metadata
1 maintainer
Release files for django-birdcage 1.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| django-birdcage-1.0.0.tar.gz | 10.2 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| django_birdcage-1.0.0-py2.py3-none-any.whl | Python 3, Python 2 | none | any | Details |
Total release size: 22.0 kB
Release files / django-birdcage-1.0.0.tar.gz
| Download URL | django-birdcage-1.0.0.tar.gz |
|---|---|
| Size | 10.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b0c60fae6092f99134b7e66f1ce4619ff3ffa74a79baf5b59f6ab54fc92f7dec
|
|
BLAKE2b-256 checksum How to use checksums |
3ca87d7c806cadd112fdaffb9ca046278d2a0694c7d41396c8e182598ff6403f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Release files / django_birdcage-1.0.0-py2.py3-none-any.whl
| Download URL | django_birdcage-1.0.0-py2.py3-none-any.whl |
|---|---|
| Size | 11.8 kB |
| Tags | Python 2 Python 3 |
|
SHA-256 checksum How to use checksums |
a8352df78df0c58d8ee9ce453abb02e18cfc630045fb6fe8b16fa436aeab94c7
|
|
BLAKE2b-256 checksum How to use checksums |
11e1449eafcb72ca77c8b671beead1fbd904a7cc616ed6d094dcb7b8beed8314
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for django-birdcage 1.0.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
