I'm looking for a method to troubleshoot custom session state on a solution that I've started supporting recently.
Current session state configuration in web.config
<sessionState mode="Custom" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="15" customProvider="DefaultSessionProvider">
<add name="DefaultSessionProvider" type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=18.104.22.168, Culture=neutral, PublicKeyToken=" connectionStringName="CMSConnectionString" />
Connection string points to production database hosted in Azure, and public key token removed from this context.
I'm seeing a SELECT and UPDATE to the UAT database (which should not be accessible to the production database).
SELECT TOP (2)
[Extent1].[SessionId] AS [SessionId],
[Extent1].[Created] AS [Created],
[Extent1].[Expires] AS [Expires],
[Extent1].[LockDate] AS [LockDate],
[Extent1].[LockCookie] AS [LockCookie],
[Extent1].[Locked] AS [Locked],
[Extent1].[SessionItem] AS [SessionItem],
[Extent1].[Flags] AS [Flags],
[Extent1].[Timeout] AS [Timeout]
FROM [dbo].[Sessions] AS [Extent1]
WHERE [Extent1].[SessionId] = @p0
SET [Expires] = @0
WHERE ([SessionId] = @1)
The parameters for the UPDATE statement reference a date from 2017 and a SessionID string that is the same for every query. I've checked my sessions table in both the production and UAT environments and neither show a SessionID or date matching those values. I've checked my system date and it's operating at the current time (UTC).
I have a few questions:
How would this statement be able to use a database that isn't the one specified in the connection string?
How am I able to troubleshoot this issue?
What may be causing this to trigger?
Where could it be retrieving this value of an expiry date from 2017 from?
Thanks in advance for any advice provided.