We fought that (or similar) issue few years back by adding something to the session early in the login flow.
Then when this became available switched to use SystemWebCookieManager. Two places - cookie auth and IdentityServer auth.
The one in the cookie auth is straight SystemWebCookieManager and the one in IdentityServer auth is customized to handle SameSite as outlined here and the backing inner cookie manager is SystemWebCookieManager.
Analyzing logs (for what might be an unrelated issue) we noticed what appears to be situations where we get all the application cookies and the auth cookie, but not _ASP.NETSessionId cookie.
Is using SystemWebCookieManager is guaranteed to put the original issue of System.Web and Katana messing up each other's cookies to rest or there are scenarios where it might still happen?
We fought that (or similar) issue few years back by adding something to the session early in the login flow. Then when this became available switched to use
SystemWebCookieManager
. Two places - cookie auth and IdentityServer auth. The one in the cookie auth is straightSystemWebCookieManager
and the one in IdentityServer auth is customized to handleSameSite
as outlined here and the backing inner cookie manager isSystemWebCookieManager
.Analyzing logs (for what might be an unrelated issue) we noticed what appears to be situations where we get all the application cookies and the auth cookie, but not _ASP.NETSessionId cookie.
Is using
SystemWebCookieManager
is guaranteed to put the original issue of System.Web and Katana messing up each other's cookies to rest or there are scenarios where it might still happen?