#28359: SecurityMiddleware's SECURE_SSL_HOST only affects unsecure requests
-------------------------------------+-------------------------------------
Reporter: Matthias Kestenholz | Owner: Irindu
| Indeera
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> For search engine optimization purposes it is preferable to have a single
> domain serving all requests. We have a custom middleware in most projects
> which handles this but dropped the middleware for sites using SSL:
>
> {{{
> from django.conf import settings
> from django.http import HttpResponsePermanentRedirect
>
> def force_domain(get_response):
> if settings.DEBUG or not settings.FORCE_DOMAIN:
> return get_response
>
> def middleware(request):
> if request.method != 'GET':
> return get_response(request)
>
> if request.get_host() != settings.FORCE_DOMAIN:
> target = 'http%s://%s%s' % (
> request.is_secure() and 's' or '',
> settings.FORCE_DOMAIN,
> request.get_full_path())
> return HttpResponsePermanentRedirect(target)
>
> return get_response(request)
>
> return middleware
> }}}
>
> We noticed today that setting `SECURE_SSL_HOST = 'example.com'` does not
> redirect requests to `https://www.example.com`
>
> It seems to me that setting `SECURE_SSL_REDIRECT` and `SECURE_SSL_HOST`
> should also handle the case where 1. a request already uses a secure
> connection but 2. the host does not equal `SECURE_SSL_HOST`.
>
> (Categorized as new feature because that's more fun.)
New description:
For search engine optimization purposes it is preferable to have a single
domain serving all requests. We have a custom middleware in most projects
which handles this but dropped the middleware for sites using SSL:
{{{
from django.conf import settings
from django.http import HttpResponsePermanentRedirect
def force_domain(get_response):
if settings.DEBUG or not settings.FORCE_DOMAIN:
return get_response
def middleware(request):
if request.method != 'GET':
return get_response(request)
if request.get_host() != settings.FORCE_DOMAIN:
target = 'http%s://%s%s' % (
request.is_secure() and 's' or '',
settings.FORCE_DOMAIN,
request.get_full_path())
return HttpResponsePermanentRedirect(target)
return get_response(request)
return middleware
}}}
We noticed today that setting `SECURE_SSL_HOST = 'example.com'` does not
redirect requests to `https://www.example.com`
It seems to me that setting `SECURE_SSL_REDIRECT` and `SECURE_SSL_HOST`
should also handle the case where 1. a request already uses a secure
connection but 2. the host does not equal `SECURE_SSL_HOST`.
--
Comment (by Tim Graham):
I'm not sure if using `SecurityMiddelware` to do canonical URL redirection
(not a security-related thing, really) is a proper separation of concerns.
Also, doesn't the patch have the possibility to be backwards incompatible?
Currently with `SECURE_SSL_HOST` set, I think it's possible to directly
access different secure subdomains. I believe this proposal prohibits that
as all secure requests will be redirected to `SECURE_SSL_HOST`.
--
Ticket URL: <https://code.djangoproject.com/ticket/28359#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.55ef08e816233e83e75775577802c1bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
