The completely naive approach would be to do:
if request.env.http_x_forwarded_for and \
request.env.http_x_forwarded_proto in ['https', 'HTTPS']:
# Is HTTPS...
But you cannot detect whether proxied traffic is real because headers are
unreliable. Instead it is up to the user to securely set up a server behind
a proxy and set the .is_proxied flag themselves.
*Example:*
We put our app server behind an SSL-terminating load balancer on the cloud.
The domain app.example.com points to the loadbalancer, so we configure app
server's Apache to allow traffic from that domain only, and block any
outside direct traffic. Then we set *auth.settings.is_proxied* to tell
web2py "this proxy traffic is legit"
HTTPS/443 requests will hit the loadbalancer, and be transformed to HTTP/80
traffic with *http_x_forwarded_for* and *http_x_forwarded_proto* headers
set. Now we can confidently check:
if auth.settings.is_proxied and \
request.env.http_x_forwarded_proto in ['https', 'HTTPS']:
# Is HTTPS...
In other words *http_x_forwarded_for* header is useless. To be able to
handle proxy-terminated SSL, we need to know that *all* the traffic is
proxied.
On Friday, September 21, 2012 8:40:35 AM UTC-4, Massimo Di Pierro wrote:
>
> Can you suggest a way to detect that?
>
> On Thursday, 20 September 2012 13:56:55 UTC-5, Yarin wrote:
>>
>> @Massimo - that'd be great.
>>
>> One more kink to throw in is recognizing proxied SSL calls. This requires
>> knowing whether you can trust the traffic headers (e.g. having apache
>> locked down to all traffic except your load balancer), so maybe we need a
>> trust_proxied_ssl or is_proxied setting somewhere?
>>
>> if request.env.http_x_forwarded_for and request.env.http_x_forwarded_proto
>> in ['https', 'HTTPS'] and auth.settings.is_proxied:
>>
>>
>>
>> On Thursday, September 20, 2012 12:52:22 PM UTC-4, Massimo Di Pierro
>> wrote:
>>>
>>> I think we should do something like this.
>>>
>>> I think we should have auth.settings.force_ssl_login
>>> and auth.settings.force_ssl_login.
>>> We could add secure=True option to existing requires validators.
>>>
>>> This should not be enforced from localhost.
>>>
>>>
>>> On Thursday, 20 September 2012 09:07:14 UTC-5, Yarin wrote:
>>>>
>>>> A proposal for improving SSL support in web2py
>>>>
>>>> For authenticated web applications, there are two "grades" of SSL
>>>> implementions: Forcing SSL on login, vs forcing SSL on the entire
>>>> authenticated session.
>>>>
>>>> In the first case, HTTPS is forced on login/registration, but reverts
>>>> back to HTTP upon authentication. This protects against passwords from
>>>> being sent unencrypted, but won't prevent session hijacking as the session
>>>> cookie can still be compromised on subsequent HTTP requests. (See
>>>> Firesheep <http://codebutler.com/firesheep> for details). Nonetheless,
>>>> many sites choose this approach for performance reasons, as SSL-delivered
>>>> content is not cached by browsers as efficiently (discussed on 37signals
>>>> blog<http://37signals.com/svn/posts/1431-mixed-content-warning-how-i-loathe-thee>
>>>> ).
>>>>
>>>> In the second case, the entire authenticated session is secured by
>>>> forcing all traffic to go over HTTPS while a user is logged in *and*by
>>>> securing the session cookie so that it will only be sent by the browser
>>>> over HTTPS.
>>>>
>>>> (Also discussed in web2py users group - Auth over
>>>> SSL<https://groups.google.com/d/msg/web2py/7qoHMs-4Va8/jRFOqYHri4gJ>
>>>> )
>>>>
>>>> web2py should make it easier to deal with these scenarios. I just
>>>> implemented a case-1 type solution and it took quite a bit of work.
>>>>
>>>> Moreover, web2py currently provides two SSL-control functions, which,
>>>> taken on their own, can lead to problems for the uninitiated:
>>>>
>>>> - session.secure() will ensure that the session cookie is only
>>>> transmitted over HTTPS, but doesn't force HTTPS, so that for any
>>>> subsequent
>>>> session calls made over HTTP will simply not have access to the auth
>>>> session, but this is not obvious (Correct me if I'm wrong)
>>>> - request.requires_https() (undocumented?) is a misnomer, because
>>>> if forces HTTPS but then assumes a case-2 scenario and secures the
>>>> session cookie
>>>>
>>>>
>>>> *Proposals:*
>>>>
>>>> - SSL auth settings
>>>> - auth.settings.force_ssl_login - Forces HTTPS for
>>>> login/registration
>>>> - auth.settings.force_ssl_session - Forces HTTPS throughout an
>>>> authenticated session, and secure the session cookie (If True,
>>>> force_ssl_login
>>>> not necessary)
>>>> - Other more granular controls
>>>> - @requires_https() - decorator for controller functions that
>>>> forces HTTPS for that function only
>>>> - 'secure=True' option on forms ensures submission over HTTPS
>>>>
>>>>
>>>>
>>>>
--
