Set the draft security HTTP header Permissions-Policy (previously Feature-Policy) on your Django app.
Project description
Set the draft security HTTP header Permissions-Policy (previously Feature-Policy) on your Django app.
Requirements
Python 3.6 to 3.9 supported.
Django 2.2 to 3.2 supported.
Are your tests slow? Check out my book Speed Up Your Django Tests which covers loads of best practices so you can write faster, more accurate tests.
Installation
Install with pip:
python -m pip install django-feature-policy
Then add the middleware, best after Django’s SecurityMiddleware as it does similar addition of security headers that you’ll want on every response:
MIDDLEWARE = [
...
'django.middleware.security.SecurityMiddleware',
'django_feature_policy.PermissionsPolicyMiddleware',
...
]
The middleware will set the Permissions-Policy header, and also set it with the previous name Feature-Policy, for backwards compatibility with older browsers.
The header will not be set until you configure the setting to set at least one policy, as below.
(For backwards compatibility, the middleware is also importable from the alias FeaturePolicyMiddleware.)
Setting
Change the PERMISSIONS_POLICY setting to configure the contents of the header.
(For backwards compatibility, the FEATURE_POLICY setting will also be read if PERMISSIONS_POLICY is not defined.)
The setting should be a dictionary laid out with:
Keys as the names of browser features - a full list is available on the W3 Spec repository. The MDN article is also worth reading.
Values as lists of strings, where each string is either an origin, e.g. 'https://example.com', or of the special values 'self' or '*'. If there is just one value, no containing list is necessary. To represent no origins being allowed, use an empty list.
Note that in the header, domains are wrapped in double quotes - do not include these quotes within your Python string, as they will be added by the middleware.
If the keys or values are invalid, ImproperlyConfigured will be raised at instantiation time, or when processing a response. The current feature list is pulled from the JavaScript API with document.featurePolicy.allowedFeatures() on Chrome.
For backwards compatibility with the old Feature-Policy header and configuration, the value 'none' is supported in lists, but ignored - it’s preferable to use the empty list instead. It doesn’t make sense to specify 'none' alongside other values.
Examples
Disable geolocation entirely, for the current origin and any iframes:
PERMISSIONS_POLICY = {
"geolocation": [],
}
Allow autoplay from only the current origin and iframes from https://archive.org:
PERMISSIONS_POLICY = {
"autoplay": ["self", "https://archive.org"],
}
Allow autoplay from all origins:
PERMISSIONS_POLICY = {
"autoplay": "*",
}
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Hashes for django-feature-policy-3.8.0.tar.gz
Algorithm | Hash digest | |
---|---|---|
SHA256 | a1a91a57c1e2722d037dea138645518aa75809e85a586b9a40400194013fb19b |
|
MD5 | 05c1f6cac868fd8a6450f9dd28e95f5c |
|
BLAKE2b-256 | ca04ecd1d526b45c1aa238ca92b267c82a73ebcafea77b80dae2d986cad62a9e |
Hashes for django_feature_policy-3.8.0-py3-none-any.whl
Algorithm | Hash digest | |
---|---|---|
SHA256 | 020878ce3ce331fc1178f96b63b88b6d550e8e5383f0241e75693084e1f8ace6 |
|
MD5 | 5b9560b103b0c424d977daa7bbf7d03b |
|
BLAKE2b-256 | a20e43e26d196ae6e1a0db44c1a56082fc5bd3c5e6ae8a3b6b83cd920125c12f |