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.
