On Mar 15, 2011, at 12:17 PM, Corne wrote: > >> When you set your own session_id, does the corresponding session file always >> exist? > Yes, it does. I'm sure.. > >> If that's not an issue, you could try setting response.session_new = False >> before calling session.connect > I already tried that, and then it does work. > The problem we are running into is exactly this: The > response.session_new = True, and is never reset. (I guess it should do > that).
I don't offhand see any harm in setting it properly in each connect call. I'm a little unsure about the logic if the session file doesn't exist, but as long as it does it should work fine. I'll suggest a patch to Massimo, but setting it to False before your call should continue to work regardless. I'm leaning in the direction of passing in a session id argument as well, but I'd like to think about it a little more. In your case (session file always exists) it doesn't matter so much, but if someone wanted to force the creation of a session file with a particular id, the logic you're using wouldn't work, because the id gets rewritten. At any rate: you have a working solution, right? > >> Doesn't creating a session id based on the request url open up a session to >> hijacking? > The sessions are created by web2py as usual, in the request we only > add a hash to find the session back (in our case the client might have > no cookies). Internally we do also check the ip to avoid session > hijacking. > > What is stored on the disk are the normal web2py sessions. > In case that a client supports cookies it all works the normal way. > In case there are no cookies, we use the hash from the url to set the > session (using session.connect())
