Forget 2 its irrelevant- I'm only securing session for HTTPS requests, but
what I'm concerned with is maintaining the secure session even if an HTTP
request slips in.
For example, I had this in my model to force HTTPS and secure the session
(basically the same as request.requires_https()):
if request.env.wsgi_url_scheme in ['https', 'HTTPS']:
session.secure()
else:
redirect(URL(scheme='https', args=request.args, vars=request.vars))
The intended result being that when a user navigates to myapp.com, they'll
get redirected to https and dumped into whatever secure session exists. But
right now they'll always bump into the login screen instead.
Perhaps this is the purview of mod_rewrite instead of web2py, and indeed
that might be what twitter is doing, gonna look now- im just wondering if
maybe our implementation should retain the secured session separately,
instead of blowing it out whenever we recreate a new non-secured one. Open
for discussion
On Monday, October 1, 2012 12:32:00 PM UTC-4, Niphlod wrote:
>
> uhm. session.secure() is only meant to add the "Secure" bit to the cookie.
> Then it's browser's responsibility to communicate with the domain of the
> cookie only submitting that cookie over https....
> In a normal web-app, if you use http://domain.com/whatever to issue out a
> cookie, that cookie should never be set as secure if you want it back in
> the following request to http://domain.com/whatever2.
> Before calling session.secure() you should check that the user is in the
> https "realm" and all the pages requested after that 1st one are in the
> https realm, because the browser will not send the same cookie (secured)
> you issued in the https:// page to a http:// page. That's pretty much the
> "good" thing about Secured cookies: you are sure that noone can see the
> cookie your server and your user exchange.
>
> Let's think about your requirements and then see what web2py can achieve.
>
> 1) You have a user hitting https://domain.com/whatever, he logins and
> web2py issues him a secured cookie (because you want to be sure noone is
> there between your server and your user).
> 2) your user hits http://domain.com/whatever2 : at this point, because
> the 1st cookie shipped was secure, no cookie is sent back from the browser
> to the server, so it seems to web2py that your user is hitting domain.comfor
> the first time. If you want on http:// the same session data you had on
> 1), you shouldn't use session.secure() at all.
> 3) let's pretend that on 2) you don't need session at all. But you'd like
> the user to go to https://domain.com/whatever3 and send back the cookie
> he received on https://domain.com/whatever, so web2py can recognize,
> e.g., he's already logged-in.
>
> This kind of behaviour is more a browser's one than a web2py one, but
> perhaps something can be adjusted.
> Are you saying that on step 3) browser sends no cookie back to web2py ?
>
> ps: are you sure twitter uses cookies with "Secure;" ?
>
> Il giorno lunedì 1 ottobre 2012 17:43:25 UTC+2, Yarin ha scritto:
>>
>> I'm bumping up against a problem in the session.secure() implementation.
>>
>> If a session is secured, and then the app is hit with an http request,
>> the session is blown out. This happens even if the session isn't modified
>> by the http request and even if it is immediately redirected to https.
>>
>> The consequence of this is that using request.requires_https() or any
>> other SSL enforcement will cause users to be repeatedly logged out if
>> they're not accessing the site directly through HTTPS.
>>
>
>
>>
>> For instance, if I go to (http://)twitter.com, Twitter forces a redirect
>> to https://twitter.com, and if i was logged in before my session will
>> still be there. Right now it seems impossible to do this with web2py.
>>
>
--
