13

I just added this SSL middleware to my site http://www.djangosnippets.org/snippets/85/ which I used to secure only my login page so that passwords aren't sent in clear-text. Of course, when the user navigates away from that page he's suddenly logged out. I understand why this happens, but is there a way to pass the cookie over to HTTP so that users can stay logged in?

If not, is there an easy way I can use HTTPS for the login page (and maybe the registration page), and then have it stay on HTTPS if the user is logged in, but switch back to HTTP if the user doesn't log in?

There are a lot of pages that are visible to both logged in users and not, so I can't just designate certain pages as HTTP or HTTPS.

mpen
  • 272,448
  • 266
  • 850
  • 1,236
  • So... you answered your question four minutes after you posted it... are we done here? On another note, is it a good idea to be passing that cookie over unencrypted HTTP? Could it get sniffed and then used to spoof the other user's login? – Mike DeSimone May 09 '10 at 23:01
  • Yeah..they could probably hijack the session. Stealing a password is probably slightly worse than hijacking a session though. I've decided to enable secure cookies though and nothing's blown up. And I thought of the answer shortly after posting it, okay? I left it in case other people had insight.... or want to know the answer. Read the FAQ, SO encourages it :p – mpen May 09 '10 at 23:49
  • 5
    Sure ,stealing a password is worse, but why not just run the entire session under HTTPS? – Mike DeSimone May 10 '10 at 00:30
  • 1
    Given the session, can you thence change the password? – John Mee Aug 17 '10 at 23:16
  • @John Mee: It asks you for your current password before you can change it. – mpen Aug 18 '10 at 01:11
  • 1
    Any man in the middle that can sniff your session cookie can also steal your passwords using something like [SSLstrip](http://www.thoughtcrime.org/software/sslstrip/). Take a spare hour to watch the presentation and understand the vector you're trying to defend against. – Chris Wesseling Jan 19 '12 at 18:41
  • @Mike DeSimone: As I understand it, HTTPS connections are slower than HTTP ones, I guess because it has to encrypt and decrypt everything, or it can't cache it properly. I think the level of security depends on the nature of the site we're trying to protect. The one in question didn't hold much personal information. – mpen Jan 19 '12 at 23:34

2 Answers2

4

Actually, modifying the middleware like so seems to work pretty well:

class SSLRedirect:
        
    def process_view(self, request, view_func, view_args, view_kwargs):
        if 'SSL' in view_kwargs:
            secure = view_kwargs['SSL']
            del view_kwargs['SSL']
        else:
            secure = False
                
        if request.user.is_authenticated():
            secure = True
    
        if not secure == self._is_secure(request):
            return self._redirect(request, secure)
    
    def _is_secure(self, request):
        if request.is_secure():
            return True
    
        #Handle the Webfaction case until this gets resolved in the request.is_secure()
        if 'HTTP_X_FORWARDED_SSL' in request.META:
            return request.META['HTTP_X_FORWARDED_SSL'] == 'on'
    
        return False
    
    def _redirect(self, request, secure):
        protocol = secure and "https://secure" or "http://www"
        newurl = "%s.%s%s" % (protocol,settings.DOMAIN,request.get_full_path())
        if settings.DEBUG and request.method == 'POST':
            raise RuntimeError, \
        """Django can't perform a SSL redirect while maintaining POST data.
           Please structure your views so that redirects only occur during GETs."""
    
        return HttpResponsePermanentRedirect(newurl)
artu-hnrq
  • 1,343
  • 1
  • 8
  • 30
mpen
  • 272,448
  • 266
  • 850
  • 1,236
1

Better is to secure everything. Half secure seems secure, but is totally not. To put it blank: by doing so you are deceiving your end users by giving them a false sense of security.

So either don't use ssl or better: use it all the way. The overhead for both server and end user is negligible.

Wim Feijen
  • 788
  • 7
  • 9