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