Improve documentation on role or user change during SignalR connection lifetime#37289
Open
cincuranet wants to merge 3 commits into
Open
Improve documentation on role or user change during SignalR connection lifetime#37289cincuranet wants to merge 3 commits into
cincuranet wants to merge 3 commits into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the SignalR authentication/authorization documentation to clarify how authorization behaves when a user’s roles/claims change after a SignalR connection is established.
Changes:
- Adds a new section explaining that SignalR caches the authenticated principal for the lifetime of a connection, so role/claim updates aren’t reflected on existing connections.
- Provides guidance on mitigation options (closing connections or performing “current data” checks).
- Updates the bearer-token section to reference the new guidance.
| * A user is signed in with the `Editor` role and has an open SignalR connection. | ||
| * The app removes the `Editor` role from that user. | ||
|
|
||
| On the next long-poll request, the authentication middleware correctly authenticates the user without the `Editor` role. However, the hub continues to authorize the user's `[Authorize(Roles = "Editor")]` hub method invocations because `HubConnectionContext.User` still holds the principal that was cached before the role was removed. The user can keep calling `Editor`-only hub methods until the connection is closed. |
| ### Bearer token authentication | ||
|
|
||
| The client can provide an access token instead of using a cookie. The server validates the token and uses it to identify the user. This validation is done only when the connection is established. During the life of the connection, the server doesn't automatically revalidate to check for token revocation. | ||
| The client can provide an access token instead of using a cookie. The server validates the token and uses it to identify the user. This validation is done only when the connection is established. As with cookie authentication, the server doesn't automatically revalidate the user during the life of the connection to check for token revocation or for changes to the user's roles or claims. For more information, see [User and role changes during the connection lifetime](#user-and-role-changes-during-the-connection-lifetime). |
Comment on lines
265
to
+266
| > [!NOTE] | ||
| > If a token expires during the lifetime of a connection, the connection continues to work. `LongPolling` and `ServerSentEvent` connections fail on subsequent requests if they don't send new access tokens. | ||
| > If a token expires during the lifetime of a connection, the connection continues to work. `LongPolling` and `ServerSentEvents` connections fail on subsequent requests if they don't send new access tokens. |
|
|
||
| ### User and role changes during the connection lifetime | ||
|
|
||
| SignalR captures the authenticated user when a connection is established and caches it for the lifetime of the connection. The cached principal is exposed by the <xref:Microsoft.AspNetCore.SignalR.HubConnectionContext.User?displayProperty=nameWithType> property and is used to authorize hub method invocations. SignalR doesn't automatically revalidate the user during the life of the connection, regardless of the authentication scheme. This behavior applies to all schemes, including cookie authentication and bearer token authentication. |
| * A user is signed in with the `Editor` role and has an open SignalR connection. | ||
| * The app removes the `Editor` role from that user. | ||
|
|
||
| On the next long-poll request, the authentication middleware correctly authenticates the user without the `Editor` role. However, the hub continues to authorize the user's `[Authorize(Roles = "Editor")]` hub method invocations because `HubConnectionContext.User` still holds the principal that was cached before the role was removed. The user can keep calling `Editor`-only hub methods until the connection is closed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes dotnet/aspnetcore#66718.
Internal previews