One of our users (Ashley) reported a strange sequence of events when using our app. When she first brought it up in her browser - before she had a chance to enter her credentials - she got a message saying she was logged on - but with a different user's name (Robin). She tried a couple more times over the course of the next day - same result. She finally restarted her computer - after which she was able to log in normally.

Our app logs certain user activity so we were able to verify that the same session showed up for 3 days running. The grid below shows records from her WWSESSION table.

4 records returned in 0.031 seconds.   Query: SELECT sessionid, userid, firston, laston, ip FROM WWSESSION WHERE sessionid = 'cmBMsSeogd5kdsbE0'
Sessionid	        Userid	        Firston	                Laston	                Ip
cmBMsSeogd5kdsbE0	XW0033002	04/05/2023 01:52:15 pm	04/05/2023 02:17:09 pm	128.172.22.121
cmBMsSeogd5kdsbE0	XW0033002	04/05/2023 01:52:15 pm	04/06/2023 02:34:18 pm	128.172.22.121
cmBMsSeogd5kdsbE0	XW0033002	04/05/2023 01:52:15 pm	04/07/2023 09:30:52 am	128.172.22.121
cmBMsSeogd5kdsbE0	XW0033002	04/05/2023 01:52:15 pm	04/07/2023 11:11:13 am	128.172.22.121

We have a log entry from 4/5 showing that user XW0033002 (Robin) logged on. We track logon status by storing the ID in wwSession.Userid, so that first entry looks correct. The next entry, from 4/6, was Ashley who launched the app from a different machine with no connection to Robin. (That IP number is the same for every entry in their wwSession table - apparently it's tied to their load balancing system)

How the heck did Ashely get Robin's session ID from the previous day, and why would she keep getting it the next morning? The sessionTimeout is set to 1800 so no way the cookies should persist over multiple days.

As far as we know, things work normally on this site most of the time. (Though we wouldn't necessarily hear about problems from most end users - we got Ashley's report because she's on the client's staff.) This is still a bit troubling - have user sessions get crossed is something we really don't want to happen.

Trying to figure out how this could even happen...

--stein

You shouldn't have 4 entries for the same session id in the Session table. If you have more than one entry it'll pick one of those.

Can you make sure that the width of the SessionId field is wide enough to match the Web Connection size (can't recall off hand what size that is - look at the code - I think it's 17)

*** You can override this method to add additional fields to your
*** session table. Use GetField(<cFieldName>) to retrieve the value
*** from any fields you add 
CREATE TABLE ( THIS.cDataPath+THIS.cTableName ) FREE;
  (SESSIONID    varchar (17),;
   USERID      varchar (15),;
   FIRSTON     T ,;
   LASTON      T ,;
   VARS        M ,;
   BROWSER     M ,;
   IP          M ,;
   HITS		   I )

If your SessionId or UserId fields are shorter it's possible dupes get created.

+++ Rick ---

The field width is correctly set to 17 chars.

I agree that there should not be 4 entries in the session table with the same ID. I'm just trying to figure out how that happened.

VFP table? Have you checked it for table or index corruption?

In theory any expired keys should get deleted on access. I can't see from the picture are the ids expired or are they are all valid?

As Richard says if VFP tables make sure to pack and reindex occasionally. You have to watch out for session files to bloat past the 2gb limit for either dbf or memo file so the session file occasionally needs to be trimmed.

Not an issue if you use SQL Server (or other SQL engine).

+++ Rick ---

If you do use SQL for the session/request tables it's still important to keep them cleaned up. I think at some point I had well over 20 million request rows before I realized I needed to clean that up. Now I have a SQL scheduled task that handles that on a regular basis. And unlike a DBF there's no exclusive access required to keep these tables groomed.

The site in question uses SQL Server but I see that their wwSession table contains records dating back to 2020. Our app does include a utility method to clean up those tables but evidently the customer needs to a reminder to enable it.

How do I check to see if a key has expired?

--sg

Look at the timestamp. There shouldn't really be any duplicates in the table - ever. Any session dupes should overwrite the old one with the new values by updating and not create a new one. So if you have dupes it's because for some reason the key lookup is failing or some code outside of wwSession is writing to the table.

+++ Rick ---