Hello all,

Are there any concerns or issues running Web Connection when clients are using IPv6 when connecting?

I had to widen the IP address fields in the session and request log tables, but other than that, does anything else need to be done?

Thanks, Kirk

No there should be no issue - Web Connection doesn't make use of the IP Address in any way and IIS just works as is. Other than the IP Address size for capturing should be fine.

I'll be widening the default fields in the table definitions to 40 characters.

For the FoxPro table (in wwServer::SetLogging()):

#IF !WWC_USE_SQL_SYSTEMFILES
	lcLogFile = ADDBS(THIS.oConfig.cSystemFilesDataPath) + this.cLogFile

   IF !FILE(FORCEEXT(lcLogFile,"dbf"))
	  CREATE TABLE (lcLogFile) FREE ;
	     (    ;
	     TIME        T ,;
	     REQID       V(25),;
	     Script      V(80) ,;
	     QueryStr    M ,;
	     Verb 		 V(10),;
	     REMOTEADDR  V(40) ,;
	     Duration    N (5,2),;
	     MemUsed	 V (8) ,;
	     ERROR	     L ,;
	     REQDATA     M,;
	     ServerVars  M,;
	     Browser     M,;
	     Referrer    M,;
	     Result    M,;
	     Account  V(30) )
	     USE  && Close Exclusive
	     USE (lcLogFile)  ALIAS CGILOG && Reopen Shared

To update the FoxPro table the easiest is just to nuke the wwRequestLog.dbf file and let it auto-recreate.

For the SQL Server script the creation script is:

BEGIN
CREATE TABLE [dbo].[wwrequestlog](
	[time] [datetime] NOT NULL DEFAULT getdate(),
	[reqid] [varchar](25) NOT NULL DEFAULT '',
	[script] [varchar](50) NOT NULL DEFAULT '',
	[querystr] [varchar](1024) NOT NULL DEFAULT '',
	[verb] [varchar](10) NOT NULL DEFAULT '',
	[duration] [numeric](7, 3) NOT NULL DEFAULT 0,
	[remoteaddr] [varchar](40) NOT NULL DEFAULT '',
	[memused] [varchar](15) NOT NULL DEFAULT '',
	[error] [bit] NOT NULL DEFAULT 0,
	[reqdata] [text] NOT NULL DEFAULT '',
	[servervars] [text] NOT NULL DEFAULT '',
	[browser] [varchar](255) NOT NULL DEFAULT '',
	[referrer] [varchar](255) NOT NULL DEFAULT '',
	[result] [text] NOT NULL DEFAULT '',
	[account] [varchar](50) NOT NULL DEFAULT ''
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

For Sql it's easiest to manually update the field or use the following:

ALTER TABLE wwRequestLog
ALTER COLUMN remoteaddr varchar(40);

+++ Rick ---

Thanks Rick.

I was hoping there was an issue with IPv6 because I'm experiencing an issue with my installation that is something I've never experienced before in all my years of working with Web Connection.

I'm running a Web Connection 7.40 application, Windows 2016 server, with a SQL server database.

My site provides reporting for multiple clients. Each client has a client identifier, and each user is assigned to a client id. When they login, their client id stored in the session table and is retrieved on each hit in order to show the user only their data and not other clients' data. However, at some point something is occuring that is allowing one client to see another client's data, even though the correct client id is being retrieved from the session. I've checked the code and it's not a coding issue. And, this only occurs when another client hits the site and performs an action. After that, the other client can see data that isn't theirs. And, the incorrect data displays on the same hit each time. In other words, I have 4 servers running, so I can hit 3 times with the correct data returned, and then on the 4th hit, the wrong data shows. Almost like one of the servers is still serving the other client.

Luckily, this is a new site and I only have one client in production, and one demo account. So my real client hasn't had the issue because I'm not using the demo account during their hours.

It's tough to explain, but I can replicate it and have added extensive logging but still can't figure this out. And I have new clients about to start with me and I can't let them until I figure this out.

I'm willing to do a screen-share to demonstrate.

Any help is greatly appreciated.

Thanks, Kirk Allen

Pretty sure it's not directly related to the IPv6 change for IIS and Web Connection, because that's transparently handled by either. Unless you're keying off an IP address in your own code somewhere, there should be no difference between requests coming in that way vs. IPv4.

But that doesn't meean that IPv6 isn't causing other issues with browsers and the network especially if you're running in a mixed environment that supports both v4 and v6.

What could be a problem is that if you have mixed requests of IPv4 and IPv6 from the same client. Each of those addresses would identify as different users in the browser and may cause you to lose a session values/cookies. You should check your logs and see if you end up seeing both v4 and v6 entries in your log. If you do that's very likely the culprit.

To solve you can switch to one or the other, but that can be problematic as there are a number of networks/applications that can't deal with IPv6.

There are lots of issues with IPv6 that have to do with network behavior and routing - I've never used IPv6 in production and honestly never had a need. There should be very few reasons to have to resort to IPv6 especially on externally facing Web sites - it makes more sense for internal networks that run on limited IP addresses.

+++ Rick ---

Thanks Rick.

I had already switched to IPv4 and the problem was still occuring. I kinda figured out what was happening even though I don't know why. The incorrect data was being displayed becuase the .Query() I was running on the business object was running an old query that wasn't being cleared after it was run. I'm working around the problem by not sharing a SQL connection. That seems to have solved the problem.

Still not sure exactly what happened, but I think I'm ok now.

Thanks, Kirk

😄

Nice.

Certainly wouldn't be the first time that a problem gets misdiagnosed to a circumstantial change in the environment to cover up a coding issue...

Did the same just earlier today chasing my tail for an hour up the completely wrong trail...

+++ Rick ---