Red Hat Bugzilla – Bug 1001369
Enable django-secure middleware by default
Last modified: 2014-11-09 18:06:09 EST
This module ensures that most of the best practices and modern browser protection mechanisms are enabled. http://django-secure.readthedocs.org/en/latest/ Adoption for the openstack dashboard should be considered as a hardening measure.
Review request for python-django-secure: https://bugzilla.redhat.com/show_bug.cgi?id=1001474
The packages are here: https://admin.fedoraproject.org/updates/python-django-secure-1.0-1.el6 https://admin.fedoraproject.org/updates/python-django-secure-1.0-1.fc19
If I see this right, then - Django-secure is more a linter than a script targeted for a productive use - it's targeted to secure a installation, so it's good to check a config, even a default config. - but: this is especially targeted for hardening SSL installations. SSL configuration is beyond scope of this package. This package enables one to make a more secure config, but I don't see a daily use case for this to have it added by default.
@mrunge FWIW it is also middleware. The SecurityMiddleware adds these features that are not a part of django by default AFAIK: X-Frame-Options: DENY HTTP Strict Transport Security X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block SSL Redirect Detecting proxied SSL The linting like feature will give you warnings if you have settings turned off that you probably shouldn't. For example if you are using django sessions without setting HTTP_ONLY and Secure. I think of this as more of a sanity check for deployment. In theory we *should* be promoting secure by default and people *should* always use TLS for administrative console. However I acknowledge that this is probably not always practical. I will defer to your judgement as to whether this addition is practical or useful to enterprise users. Just wanted to clarify the purpose of this component.
should be documented, that it's advisable to use django-secure
Provided doc-text. Still, I don't think, we should add django-secure as a requirement to python-django-horizon. Esp. we don't ship python-django-secure as part of RHOS.