The web2py in trunk has a new uuid function that combines uuid4 (it is random) and uuid1 (takes into account mac address and time). It should void uuid conflicts when running multiple vps instances clones of each other. You may want to give it a try.
Massimo On Feb 10, 2:51 pm, Dmitri Zagidulin <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
