halter73
commented
8 months ago We think this is related to how cookies default to Cookies default to SameSite=Lax](https://chromestatus.com/feature/5088147346030592). This may be fixed by configuring IdentityServer cookies to use SameSite=None.
omarceloribeiro
Is there an existing issue for this?
Describe the bug
I am working on a project that has a Blazor WASM client and a ASP.NET Core Web API. These two apps are not hosted on the same domain. There is also an Identity Server (v3) instance, which we use to authenticate, that is hosted by the API. After setting everything up in the Blazor WASM client (the WebAPI is much older), I was able to successfully authenticate against the identity server and receive an id token, an access token, and a refresh token. However, I noticed that almost immediately after login the session storage item responsible for holding those tokens was deleted.
I came across this stack overflow post, https://stackoverflow.com/questions/65772055/blazor-webassembly-pwa-session-storage-not-persisting-after-deployment-to-azure, which helped me identify the problem. Immediately after login, the AuthenticationService.js initiates a check session request via an iframe, but because the Identity Server and WASM client are on different domains, the Identity Server cookie is not being sent along with the check session request.
Since I don't require this check session behavior, I tried to create my own options class to configure the monitorSession setting of the UserManger object that is responsible for checking the session in AuthenticationService.js. However, when I did this, set monitorSession to "false" via the options, and ran the project, I got stuck in an infinite login loop, the cause of which I can't determine.
As a stop gap, I have copied the AuthenticationService.js file to a local folder and made the first change recommended in the above stackoverflow post, where I just manually set the "monitorSession" getter to return false.
What can I do to fix this problem that doesn't involve the above stop gap. Should creating an options class and setting that variable work? Any ideas as to what's causing the infinite login loop when I tried that?
Any help is greatly appreciated!
Expected Behavior
I expected to be able to set the "monitorSession" setting without encountering an infinite login loop, but perhaps we are not meant to touch that setting.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
8.0.100
Anything else?
No response