microsoft-authentication-library-for-dotnet
microsoft-authentication-library-for-dotnet copied to clipboard
AzureAD
Fix the caching and investigate the OWIN redirect URI / challenge verb in our ASP.NET classic sample
Our ASP.NET Classic sample does not add Client_info=1 in the auhorize request and use that info for caching.
What would be the behavior in this case? I am using MSAL in an ASP.NET classic application, and I used these samples to develop my sign on implementation. I'm seeing some issues where sign on stops working in production after a period of time (redirects to sign in page after successful sign in).
I'm pulling my hair out trying to reproduce the issue in a test environment, and I'm wondering if there's a library bug that's causing this; and if so, if there's a workaround.
Is it in the case of guest users, @seannybgoode ? Which sample did you use?
Our use case is for an internal corporate application, so there wouldn't be any guest users.
I believe it would be the samples here: https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect
@seannybgoode Were you able to find a repro? Would you mind creating a separate issue with repro steps or just more details. It'll help with tracking. Thanks,
Hey again, thanks for getting back to me. I wasn't actually able to reproduce the issue in test, but I think I found the problem code.
In following the MSALConfidentialClientApplicationBuilder example, I had made a mistake where the in memory token cache was declared outsite the if (null) statement:
Further, since that class (roughly, in fairness) follows a signleton pattern, I decided that some thread safety was in order:
Obviously, initializing a new memory cache whenever that method is called would cause unpredictable behavior with the existing tokens in the cache.
Closing as duplicate of https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/3285