Rick,

I upgraded two client production servers to v6 two months ago. The SQL wwsession table's SessionID column was expanded to char(17). Well past the cookie expiration of 4 hours, users reported not being able to past the login page. Client support had each of them delete the cookies and try again. That seemed to work as they each gained access.

Since then, we continue to receive intermittent calls with the same issue. I cannot duplicate on my end and cannot be 100% assured the problem is returning to the same workstation after the cookie was deleted.

Looking at the wwsession table, I have two questions for you. A user currently having the login problem has a 14 character SessionID. That workstation apparently has not ever deleted the cookie. Even though the session ID is from WW v5, is there any reason it would not work in the expanded column width?

I am also seeing duplicate SessionIDs in the table. I assumed they should be unique. I deleted all session ID's yesterday and see many dupes today, of both 14 and 17 char lengths. Screen shot below.

Thanks

~bob

Make sure the field is at least 17 characters wide and are VARCHAR. There was a recent change to switch over to varchars() to make the data access more readable (without all the PADR() code).

Best thing to do is blow away your wwSesison table and let it recreate.

If you still have dupes there's soemthing else going on - like a short timeout perhaps? You can have multiple same Session ids in the table if ids have expired and are reaccessed after the timeout.

+++ Rick ---

Thanks. Changing the SQL column from CHAR(17) to VARCHAR(17) seemed to work.

UPDATE: That did not fix it afterall. Two clients have now reported the problem again. I found their session ID's in the SQL wwsession table.

Here is a screen shot of the wwSession SQL table with one example highlighted in yellow.

There were two records with the same session ID. Both were created 24 hours ago at the same time. The session timeout I use is four hours.

If I delete the first session record (with the expired timestamp), the user is able to login.

It appears the user login initially succeeds when the ID and password is entered. After the redirect to the main page, authenticate() finds the expired record, returning the user to the login page.

You say two session records with the same session ID is expected in your logic?

Within my app's AdminProcess is this code, which has been in use for ten years or so, for every hit.

THIS.InitSession("RigStat", (60*60*4), .T.)
SESSION = THIS.oSession
DODEFAULT()

...

IF !PROCESS.Authenticate()
   RETURN .F.
ENDIF

There is no additional code at the page level.

These problems just started after I upgraded my production servers to ww v6.

Where would I start to look?

~bob

Rick,

In this example, a user has three session records from his workstation, with two having identical timestamps.

That user cannot log into the system.

Is this record creation by design in your wwsession logic? Or should I be looking for the problem on the query side?

Thanks

~bob

That should not happen if everything is working properly.

You can have multiple session entries with the same id if tokens are expired, but you shouldn't have multiples of the same. Once they're in there though they will be updated in sync (and it shouldn't really hurt anything) because an update statement is doing the updating.

I would suspect perhaps mismatched versions of clients accessing the table or old data from older compiled versions? Try nuking the table of sessions and then see if the problem returns.

+++ Rick ---

Rick,

I blew away wwsession as you suggested and recreated using the Console Create SQL Table option.

The sessionid column therein was created as a char(14).

Console.exe is v6.0.1.0 dated 9/20/2016 extracted from WebConnection-6.07.0.exe.

Is this the correct version?

~bob

Hi Bob,

The console isn't the problem in this case - it's the westwind.sql script and it looks like the code in there is out of date - the build routine has been pulling an old file.

I'm getting ready to push out a new release in the next few days so I'll get that fixed. For now changing the width to 17 should do the trick.

FWIW, the date looks right on the Console, but the version number didn't get rev'd properly.

+++ Rick ---

Just a quick heads up - I had a chance to double check this after fixing the template properly and it seems to be working now.

You can use the following SQL in templates\westwind.sql:

CREATE TABLE [dbo].[wwsession](
	[SessionID] [varchar](17) NOT NULL,
	[UserId] [varchar](15) NOT NULL,
	[firston] [datetime] NOT NULL,
	[laston] [datetime] NOT NULL,
	[vars] [text] NOT NULL,
	[browser] [varchar](155) NOT NULL,
	[ip] [varchar](20) NULL,
	[hits] [int] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Went through a number of iterations of logging in and out and anonymous browsing and that's working properly.

This will be in the 6.10 update in the next day or two.

+++ Rick ---

Hi Rick & all,

I was browsing this topic because I have a user running my WWC app (5.70) using an iPad mini that is complaining he gets kicked out of the session all the time and has to keep logging back in. (I haven't seen this elsewhere with other users.) I instructed him to make sure that he had Safari set to allow cookies, which he did. That didn't seem to fix it.

So I just doubled the timeout setting in the app (I think) by changing my code to create the session to this:

FUNCTION Process *lcSessionCookieName, lnTimeoutSeconds, llPersist THIS.InitSession("RFCWeb",2400) *Session = THIS.oSession DODEFAULT() RETURN ENDFUNC

Not sure if this made any difference yet

I saw the discussion here about the wwSession structure, but for one thing my app is using a VFP wwSession table, and I just tried expanding the sessionid field from Char(14) to VarChar(17), and that bombed. Kept kicking me out as well.

So just trying to anticipate because my user is under deadline, I was wondering if there are any other settings I should look at.

Thanks, Rod

There's no reason that it shouldn't work on iPad. If they have a problem make sure you have them log out and effectively reset their session (your logout code should ensure that the Cookie is destroyed - it is if you use the standard Web Connection logout of Authenticate("LOGOUT"). This will ensure that the user gets a new session id that is valid and has the right length etc.

It might also help to ensure clear out the wwSession table - if it has old shorter ids in there it can cause problems. When ever something is changed with the ID format you pretty much have to clear out old sessions.

+++ Rick ---