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



Mozilla Labs
5 years ago
5 years ago


(Reporter: Ryan Pitts, Unassigned)





5 years ago
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:

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.

Comment 1

5 years ago
I just realized I ought to clarify exactly which VM I'm talking about. The dev box for Source is

Comment 2

5 years ago

Looking at the load balancer settings for, 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?


Comment 3

5 years ago
Yep, it looks like that should work. When I inspect the headers for a request to, though, I'm not seeing that header.

Comment 4

5 years ago

I believe 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 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.)

Comment 5

5 years ago
Hmm, I'm still not seeing it. I'm looking at the results of:

$ curl -I

Comment 6

5 years ago
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

If I log onto the VM and sniff the packets via tcpflow, I see:

[my machine to source-dev1]

--- begin header ---
Source: : 35731 (
Destination: yyy.yyy.yyy.yyy : 80 (

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
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 (
Destination: : 35731 (

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

Comment 7

5 years ago
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!

Comment 8

5 years ago
Aaaaand we're in business. Thank you for setting this up.
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.