| Summary: | Enable django-secure middleware by default | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Grant Murphy <gmurphy> | |
| Component: | python-django-horizon | Assignee: | Matthias Runge <mrunge> | |
| Status: | CLOSED WONTFIX | QA Contact: | Ami Jeain <ajeain> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | unspecified | CC: | aortega, ddomingo, gmurphy, hateya, jpichon, mjc, mrunge, yeylon | |
| Target Milestone: | --- | Keywords: | Triaged | |
| Target Release: | 4.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Enhancement | ||
| Doc Text: |
When setting up a Django application such as Horizon, there are common issues. It is recommended to set up service horizon via SSL. Additionally one can use python-django-secure, which provides a script, to check if the currently configured solution is safe.
More information about django-secure can be found at it's online docs http://django-secure.readthedocs.org/en/latest/
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1032303 (view as bug list) | Environment: | ||
| Last Closed: | 2013-11-19 08:38:30 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Bug Depends On: | 1001474 | |||
| Bug Blocks: | 1032303 | |||
|
Description
Grant Murphy
2013-08-26 23:13:04 UTC
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. |