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?
