User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release) Build ID: 20130618035212 Steps to reproduce: I'm trying to use django-browserid to add login functionality for a new feature. It works properly on my local machine, under standard http. Actual results: The dev site for Source is served https, and the django-browserid logins are failing. We discovered that browserid was posting to http instead. The problem appears to trace back to requests being sent through a proxy, as described here: https://docs.djangoproject.com/en/1.4/ref/settings/#secure-proxy-ssl-header It doesn't appear that there are any headers being sent from the proxy that designate whether the request is https. I have tested request.is_secure(), which is used to browserid to determine how to post, and found that it returns false no matter what. Even when the page is clearly https. Expected results: Is it possible to have such a header added? I'm hoping that if I can use the SECURE_PROXY_SSL_HEADER setting, this will resolve the login issue.
I just realized I ought to clarify exactly which VM I'm talking about. The dev box for Source is source-dev1.vm.labs.scl3.mozilla.com
Ryan: Looking at the load balancer settings for source-dev.mozillalabs.com, it looks like: 1) all HTTP traffic is rewritten to HTTPS and 2) there is a rule that sets a header "X-SSL" to "On" If I understand the link you posted correctly, would the following work? SECURE_PROXY_SSL_HEADER = ('HTTP_X_SSL', 'On')
Yep, it looks like that should work. When I inspect the headers for a request to https://source-dev.mozillalabs.com/en-US/, though, I'm not seeing that header.
Ryan: I believe source-dev.mozillalabs.com should now see an "X-Forwarded-SSL" header set to "True" for SSL-wrapped requests to that server. Can you please verify this is the case? (The rule that I mentioned earlier is 1) not being applied to responses coming IN to source-dev.mozillalabs.com and 2) doesn't have a check to make sure that connections were wrapped in SSL before coming to the load balancer. The new rule that I added should do both.)
Hmm, I'm still not seeing it. I'm looking at the results of: $ curl -I https://source-dev.mozillalabs.com/en-US/
I think what you are seeing is the headers on the response sent back by the server. I was assuming that the special SSL header needs to go onto the traffic going IN to source-dev-mozillalabs.com. If I log onto the VM and sniff the packets via tcpflow, I see: [my machine to source-dev1] --- begin header --- Source: xxx.xxx.xxx.xxx : 35731 (labs-load-balancer.vm.labs.scl3.mozilla.com) Destination: yyy.yyy.yyy.yyy : 80 (source-dev1.vm.labs.scl3.mozilla.com) GET /en-US/ HTTP/1.1 User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8x zlib/1.2.5 Accept: */* Cache-Control: no-cache X-Forwarded-SSL: True Host: source-dev.mozillalabs.com X-Cluster-Client-Ip: zzz.zzz.zzz.zzz ---- end header ---- [response from source-dev1] --- begin header --- From request: GET /en-US/ HTTP/1.1 Source: yyy.yyy.yyy.yyy : 80 (source-dev1.vm.labs.scl3.mozilla.com) Destination: xxx.xxx.xxx.xxx : 35731 (labs-load-balancer.vm.labs.scl3.mozilla.com) HTTP/1.1 200 OK Date: Fri, 16 Aug 2013 16:58:55 GMT Server: Apache/2.2.15 (CentOS) Expires: Fri, 16 Aug 2013 17:13:56 GMT Vary: Cookie Cache-Control: max-age=900 x-frame-options: DENY Set-Cookie: anoncsrf=<string>; expires=Fri, 16-Aug-2013 18:58:56 GMT; httponly; Max-Age=7200; Path=/ Last-Modified: Fri, 16 Aug 2013 16:58:56 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 ---- end header ----
Ahhhh, yes that makes sense now! I'll add SECURE_PROXY_SSL_HEADER to the dev settings and see if that clears things up. Thank you!
Aaaaand we're in business. Thank you for setting this up.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.