More details. The session bleed issue is happening because of a code change (not a random environment leak). We've replicated it twice -- applied the 2 code changes (described below), immediately get complaints about session bleed, roll back the changes, everything's fine.
The problem is, I can't see how the changes in question would lead to messed up sessions. They are: 1) Cache-control statements. Specifically, in one controller, inserted the following line: response.headers['Cache-Control'] = 'max-age=3600, must-revalidate' and in another, response.headers['Cache-Control'] = 'store, no-cache, must-revalidate' 2) A change in where to redirect the user after login. was (in db.py): auth.settings.login_next = 'https://appurl/user_home' changed to: auth.settings.login_next = 'http://appurl/user_home' But how could this be? Why would changing the browser cache-control headers, or redirecting to an http url instead of https, cause one user to get another user's session (and see the other user's account, etc)? On Feb 10, 10:50 am, Dmitri Zagidulin <dzagidu...@gmail.com> wrote: > Sure. > So, this is the query that was run when session bleed was first > encountered: > select unique_key, count(unique_key) from sessions.web2py_session_init > group by unique_key having count(unique_key) > 1; > It yielded: > '0d7c9e95-ca8c-4c05-8e5f-69d058ea6510', 2 > '29e390f6-f901-4312-bc5c-f42c5c4e53e7', 2 > and 13 more rows like it, 15 instances of duplication in total. > > The distribution in time is somewhat odd: 8 of the duplicates > instances happened on 1/25, 4 on 1/26, 1 on 1/28, 2/04 and 2/08 > respectively. > > The rows in question look like this: > id, locked, client_ip, created_datetime, modified_datetime, unique_key > 2231, b, '192.xxx.xxx.xxx, '2010-01-25 10:53:05', '2010-01-25 > 10:53:05', 'd8f159bf-bdc4-4059-b4bb-307eb4880813' > 2236, b, '192.xxx.xxx.xxx', '2010-01-25 10:53:05', '2010-01-25 > 10:53:05', 'd8f159bf-bdc4-4059-b4bb-307eb4880813' (same ip address) > ... > 312220, b, 'xxx.xxx.xxx.162', '2010-02-08 10:43:17', '2010-02-08 > 15:48:07', 'a18b5ff2-c532-4c3d-840e-880ab77d943b' > 312219, b, 'xxx.xxx.xxx.68', '2010-02-08 10:43:17', '2010-02-08 > 10:43:17', 'a18b5ff2-c532-4c3d-840e-880ab77d943b' (different ip > addresses) > > The traffic load is harder to judge, but about 16,000 session entries > in the db a day (as of 2/08). > Although now that I think about it, the most likely reason why 8 of > the duplicate session instances happened on 1/25 was because we were > doing heavy load testing (using twill) on that day. So that's likely > correlated. > > The setup is: load balanced between 3 apache/wsgi servers, virtualized > via VMWare. So your comment about cloned systems and uuid gives me > pause -- the 3 servers are probably clones of each other. > > Several questions: > 1) I noticed that the session keys are generated by the uuid4 > function. Would it help any to switch to uuid1? > 2) In addition to the session key, web2py also stores the session row > id, in the session cookie. Why is that? Was there some doubt that the > session key would be unique, when you implemented that part of the > code? > > 3) On 2/08, the database shows only one instance of duplicate session > keys. However, there were about 20 reports of users' sessions being > crossed over (and users seeing other users' accounts when logged in). > So those two things don't seem to be directly correlated. We're still > trying to diagnose this session bleed issue, rolling back revisions > and hoping to see if it was a code issue or an environment leak > somehow. > > Thanks! > > On Feb 9, 9:49 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > This is not normal. > > Can you share more details about the setup? The amount of traffic and > > the problem you encountered? > > > In web2py all sessions are uuid and the probablility that two uuid are > > the same is null (unless these machine are one clone of the others in > > which case I am not sure how the python uuid depends on the time and > > ip of the machine. > > > Massimo > > > On Feb 9, 11:30 am, Dmitri Zagidulin <dzagidu...@gmail.com> wrote: > > > > I've been experiencing some session bleed across accounts (several > > > instances of users crossing over into other users' sessions, and being > > > able to see other users' accounts). And while investigating that (by > > > the way, has anybody else run into this?), I've noticed that the > > > database in which I keep my sessions has several duplicate session > > > keys. > > > > So, my main question is -- is this by design, or is something wrong? > > > When you store sessions in database (using session.connect - to MySQL > > > in this case), are there supposed to be duplicate entries with the > > > same uuid/session key? Would it benefit me to put in a unique > > > constraint on the unique_key db column? > > > > A little more about my setup: > > > web2py version 1.67.2 > > > running behind Apache/WSGI, load balanced across 3 servers. (Hence why > > > I'm keeping sessions in a db rather than on disk). > > > Sessions being stored in a MySQL db. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
