SecurityMiddleware's SECURE_SSL_HOST only affects unsecure requests

[Matthias Kestenholz]

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.

[Matthias Kestenholz]

​PR

[Irindu Indeera]

HI I'd like to work on this issue, but I am a newbie to open source, I am currently a computer engineering undergraduate, I am confident that I'll be able to contribute but I need some mentoring, Mr Matthias Kestenholz can you please help me

[Matthias Kestenholz]

You could help review the proposed feature itself and also the pull request: ​https://github.com/django/django/pull/8698

A good idea would also be to follow the ticket triaging steps as documented here: ​https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#unreviewed

[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.