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