yes the second- im thinking more and more that session.secure() should create a whole new secure session cookie, rather than trying to secure the existing one- it seems like that's the only way to effectively handle mixed mode- but I'm not familiar enough with the implementation to know how much work that would be- I'll leave it to you to make that call
On Monday, October 1, 2012 3:24:19 PM UTC-4, Niphlod wrote: > > maintaining as in "use that session also for http" ? if that's the case, > there is no issue: secured cookies are sent only back to a https, so it's a > no-go. > > if "maintaining" is meant as "retrieve the previously issued cookie only > for https pages" then we can inspect it further. Generally web2py does > nothing to "delete" a created cookie: it's browser's job to send it back > (but I'm not sure how them behave in "mixed" mode, i.e. some requests to > http and some to https.) > I'm going to test it. > > On Monday, October 1, 2012 7:07:17 PM UTC+2, Yarin wrote: >> >> 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.com for 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. >>>> >>> --
