Right now the session is a combination of client ip and a uuid. The uuid prevents session hijacking.
The ip serves two purposes: - the server can find expired sessions more easily - the apps the reject sessions coming from wrong ip thus further protecting against hijacking. On Mar 15, 11:55 am, Jonathan Lundell <jlund...@pobox.com> wrote: > On Mar 15, 2011, at 7:15 AM, Corne wrote: > > > > > > > > > > > > > We (again) looked deeper into what is really happening; and it is yet > > different. > > > What we ran into is the following: > > We tried to set a session_id our self based on information in the url, > > which in this case resulted in calling the session connect code (where > > it went wrong) twice per request. > > > In case a cookie was send; there is no problem at all. > > Session is handled by web2py like always (except for the fact that > > it's done twice). > > In case there is no cookie send; there is a problem. > > The first call to connect (web2py internal) has no session_id, so a > > new one is generated. > > The second call to connect (our plugin) has a session id so it's > > handled ok. > > > In the end of the request, the session changes are written. But in our > > case (without cookie) the var session_new is True (and the session > > file is (re)opened with 'wb'). > > Opening with 'wb' does seem to change the file handle. The request > > that is handled by a differend process at the same time will now have > > an invallid session. > > > This also explains the fact that reopening the session file seemed to > > solve the problem except for the fact that the real problem is > > somewhere else. > > > I guess that using connect is something that is / should be allowed > > (it's in the book), this is also the way to, for example use sessions > > from an other application. > > and there the same issue could apply: > > in case someone uses connect to just use a session from a different > > application. The first connect from web2py might result in creating a > > new session. While the connect which is issued later by the user does > > result in an existing session. > > When you set your own session_id, does the corresponding session file always > exist? If it does not, session.connect is going to discard that session_id > and generate a new uuid. I don't see a way to force session.connect to create > a session file with a predetermined id. > > If that's not an issue, you could try setting response.session_new = False > before calling session.connect; session.connect probably ought to do that > itself at the beginning of the not-db logic branch. We could also add a > session-id argument to allow the caller to force an id, I suppose, but I'd > like to be a little clearer on your use case. > > Doesn't creating a session id based on the request url open up a session to > hijacking?
