Closed Bug 902683 Opened 11 years ago Closed 11 years ago

request.is_secure() is failing on the Source dev site

Categories

(Mozilla Labs :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: ryan.a.pitts, Unassigned)

Details

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
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.