Skip to main content

Utilities for maintaining forwards compatibility with Django releases.

This project has been archived.

The maintainers of this project have marked this project as archived. No new releases are expected.

Project description

https://img.shields.io/pypi/pyversions/django-birdcage.svg https://img.shields.io/pypi/v/django-birdcage.svg https://img.shields.io/pypi/status/django-birdcage.svg https://img.shields.io/pypi/l/django-birdcage.svg

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.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… :-)

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django-birdcage-0.8.1.tar.gz (6.6 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

django_birdcage-0.8.1-py2.py3-none-any.whl (7.8 kB view details)

Uploaded Python 2Python 3

File details

Details for the file django-birdcage-0.8.1.tar.gz.

File metadata

File hashes

Hashes for django-birdcage-0.8.1.tar.gz
Algorithm Hash digest
SHA256 565533a154a325fad90c248080c316a3747bfec11cadb858e5486d2ffa8bd585
MD5 1416ddaf1a7ef1d88a8b4f3014bd9e95
BLAKE2b-256 cdbc8cabb1c36a28e58740ed2615bd46123641f53d08e967c98991deb1295d52

See more details on using hashes here.

File details

Details for the file django_birdcage-0.8.1-py2.py3-none-any.whl.

File metadata

File hashes

Hashes for django_birdcage-0.8.1-py2.py3-none-any.whl
Algorithm Hash digest
SHA256 78a492fdf5164ae0227706243a245b398b41a4fb1ad390adca3c15fcfc36830d
MD5 0bb033b27411dd1daa21b2af4b2c2072
BLAKE2b-256 0503919c4fa14f4994f4c93953bb8c09b44a8dc52bfbb762b2c32bd246a24a45

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page