-
Notifications
You must be signed in to change notification settings - Fork 10.3k
On each circuit connection up, update the User in authentication state #12051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
How would this work for long-polling though? Since one SignalR connection spans multiple requests that implies that each message (and each long-polling request) has its own principal. Does SignalR do something special here? |
Yes, we clone the |
If we update the authentication state's
|
Done in #12421 |
This is for server-side Blazor and will address most of the issues with using Windows authentication.
Currently the built-in internal default
FixedAuthenticationStateProvider
assumes the authentication state is fixed for the lifetime of the circuit, as its name implies. However this isn't adequate for Windows authentication, as theWindowsPrincipal
is connected to underlying OS services and can't continue to be used if the original HTTP request has completed. Trying to call things likeIsInRole
will throw if the principal has already been disposed, which would happen if:To resolve this, we need some extra logic that, whenever the circuit connection becomes up (equivalent to
OnConnectionUpAsync
on a circuit handler), we grab the latestUser
from theHubContext
(orHttpContext
if we must, butHubContext
is more correct) and pass it to the built-in authentication state provider, which can update its own internal state and call its ownNotifyAuthenticationStateChanged
.Caveat
This will fix most scenarios, but one case will remain: if the user is currently disconnected and some background process is trying to call APIs like
IsInRole
on theirClaimsPrincipal
, this will still throw. There's nothing we can do about that short of adding features at the IIS integration layer, which would have other drawbacks so we might never want to do that. Basically, developers should only be using Windows authentication for intranet apps where transient disconnection is not something that will happen, or they do their own error handling if it does.The text was updated successfully, but these errors were encountered: