A successful membership removal stops new requests, but an existing SignalR connection may still carry an earlier principal and tenant group membership. Those are separate surfaces.
Track the minimum live state
Keep an in-process registry from tenant and connection ID to user ID. Avoid tokens, email addresses, and message bodies. A per-tenant gate coordinates admission, revocation, and outgoing broadcasts.
Validate both directions
On connection, check the exact tenant, membership version, and security stamp against the live row before joining the group. A hub filter repeats that check before each client-invoked method. A method check does not stop group delivery, so after a successful membership commit, remove the user's matching connection IDs from that tenant group.
State the ordering guarantee
A chat broadcast takes the same tenant gate and rechecks its sender before saving or sending. Once the removal response returns, a later broadcast cannot select the removed connection. A frame already dispatched before removal cannot be recalled.
Test an established connection
Hold real SignalR clients open during owner removal. The remaining member receives a subsequent message. The removed member receives none, its next send fails, and no rejected text appears in persistence. New-negotiation and tenant-isolation tests still run.
This registry is single-node. A multi-node deployment needs shared revocation coordination or a managed SignalR service. The next episode transfers ownership atomically.
Watch the 6-minute lesson: https://youtu.be/RFI5AaHbzMU
Top comments (0)