Awesome thanks Massimo- will test tonight
On Thu, Oct 4, 2012 at 4:13 PM, Massimo Di Pierro <
massimo.dipie...@gmail.com> wrote:
> OK. check trunk. Auth(db,secure=True).
>
>
> On Thursday, 4 October 2012 13:01:51 UTC-5, Yarin wrote:
>>
>> Yes exactly
>>
>> On Thursday, October 4, 2012 12:38:34 PM
OK. check trunk. Auth(db,secure=True).
On Thursday, 4 October 2012 13:01:51 UTC-5, Yarin wrote:
>
> Yes exactly
>
> On Thursday, October 4, 2012 12:38:34 PM UTC-4, Massimo Di Pierro wrote:
>>
>> So... would replaing this in gluon.main.py
>>
>> is_https = env.wsgi_url_scheme in ['https', 'HTTPS']
Yes exactly
On Thursday, October 4, 2012 12:38:34 PM UTC-4, Massimo Di Pierro wrote:
>
> So... would replaing this in gluon.main.py
>
> is_https = env.wsgi_url_scheme in ['https', 'HTTPS'] or env.https=='on')
>
> with
>
> is_https = env.wsgi_url_scheme in ['https', 'HTTPS'] or env.https=='on' or
So... would replaing this in gluon.main.py
is_https = env.wsgi_url_scheme in ['https', 'HTTPS'] or env.https=='on')
with
is_https = env.wsgi_url_scheme in ['https', 'HTTPS'] or env.https=='on' or
request.env.http_x_forwarded_proto in ['https', 'HTTPS']
address the first issue?
Massimo
On T
I'm revising my stance on this. After further digging around, I'm gonna go
with Niphlod's position that securing only the login traffic without
securing the entire session is for the most part pretty worthless. While
this might have value to some sites that have to deal with mixed content,
the
Done http://code.google.com/p/web2py/issues/detail?id=1023
On Friday, September 21, 2012 2:05:41 PM UTC-4, Massimo Di Pierro wrote:
>
> Yarin, please open an issue on google code as suggested enhancement so ti
> does not get lost. Also feel free to move the discussion on web2py
> developers.
>
>
Yarin, please open an issue on google code as suggested enhancement so ti
does not get lost. Also feel free to move the discussion on web2py
developers.
On Friday, 21 September 2012 12:22:57 UTC-5, Yarin wrote:
>
> Here's a complete example of our own implementation (simplified, untested)
> us
Here's a complete example of our own implementation (simplified, untested)
using the proposed auth settings:
in our model:
def force_https(trust_proxy = False, secure_session = False):
""" Enforces HTTPS in appropriate environments
Args:
trust_proxy: Can we trust proxy header '
You can't detect this- it must be a setting. Please see my previous answer:
https://groups.google.com/forum/#!msg/web2py/me1e5d6Dudk/VQRQhdiryccJ
"you cannot detect whether proxied traffic is real because headers are
unreliable. Instead you must securely set up a server behind a proxy and
set th
Yes but how do you detect if is_proxied reliably?
On Friday, 21 September 2012 10:28:26 UTC-5, Yarin wrote:
>
> FYI this is the enforcer function we wrote for our implementation-
> basically a rewrite of request.requires_https():
>
> def force_https(trust_proxy = False):
> """ Enforces HTTPS in
FYI this is the enforcer function we wrote for our implementation-
basically a rewrite of request.requires_https():
def force_https(trust_proxy = False):
""" Enforces HTTPS in appropriate environments
Args:
trust_proxy: Can we trust proxy header 'http_x_forwarded_proto' to
determine SSL
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
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 t
>
> Wrong- this is a matter of protecting the user. I may have a site that
> doesn't deal with anything important. Let's say it allows users to see
> their friends' baby pictures. They need to login so that we know what
> babies to show. Session gets hijacked? Big deal, you can see someone else
@Niphlod
1) "only valid point here is a sort of "netiquette" among web developers"
Wrong- this is a matter of protecting the user. I may have a site that
doesn't deal with anything important. Let's say it allows users to see
their friends' baby pictures. They need to login so that we know what
@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 somewher
Well, this list is often used to discuss "good behaviours", so, let's
brainstorm.
> - Is a hijacked session the same as an exposed password? a hijacked
> session compromises a single session on a single system, while a stolen
> password constitutes a cross-session and (because passwords are r
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
Was wrestling with these points myself...
With respect to case-1 adding 0% security:
- Is a hijacked session the same as an exposed password? a hijacked session
compromises a single session on a single system, while a stolen password
constitutes a cross-session and (because passwords are re-use
ok, i got the point on having a hard time implementing case-1 with web2py.
Please humour me, what I didn't got over those kind of requirements is
basically...case-1 adds 0% security.
If there is a man in the middle, he can "scoop" the cookie just as he would
scoop the password in the case of
20 matches
Mail list logo
