[Bug] You still see (and can call) yourself in the video-call picker — self-filter compares sub against ChatHub's sid #898

New Issue

2026-07-30T02:05:40Z

spikerj commented

2026-07-30 02:05:40 +00:00

Summary

The video-call picker lists the current user, and clicking yourself starts a call that rings your own browser. This is the residual root cause behind #98 — that ticket fixed the reactivity race (read userIdSig instead of the mutated userId string), but the filter it repaired compares two different Keycloak claims, so it never matches regardless of timing.

Root cause — two ID spaces

ChatHub.OnConnectedAsync stores the roster entry with Id = sid (Keycloak session id) — SpikerSoft.Contracts.SignalR/ChatHub.cs:205. The whole of ChatHub is sid-keyed (DM participants, rooms, history).
Angular sets chatService.userId / userIdSig from keycloak.loadUserProfile().id, i.e. the sub user id — _services/chat/chat.service.ts:98-99 and :438-439.

So u.id (sid) !== selfId (sub) is always true and the filter is a no-op:

_dialogs/video-call-picker/video-call-picker.component.ts:324-327
_components/chat/chat.component.ts:64-72 (same broken filter, DM list)

The backend self-guard is defeated by the same skew:

// VideoCallHub.cs:187-188
if (calleeUserId == callerId)   // calleeUserId is a sid, callerId is GetCurrentUserId() = sub
    throw new HubException("Cannot call yourself");

And because #99's fix subscribes each connection to a user-group for every claim variant (GetAllUserIdentifiers, VideoCallHub.cs:394-408), Clients.Group(UserGroup(calleeUserId)) delivers the invite straight back to the caller's own browser. The two fixes compose into a working self-call.

Why the tests didn't catch it

video-call-picker.component.spec.ts:56-61 sets userIdSig = signal("me") alongside a user("me") — ids constructed to match, so it passes whatever the real claim skew is.

Fix

Backend — VideoCallHub.InviteUser guards against GetAllUserIdentifiers() rather than GetCurrentUserId() alone, so a sid-addressed self-invite is rejected. Immune to ID-space drift (compares within one connection's own claims).
Frontend — align chatService.userId / userIdSig to the sid claim so it matches the roster identity ChatHub actually broadcasts. Every consumer of chatService.userId is hub-facing (chat.component.ts:177,182,238, chat.service.ts:371), so this also fixes DM "other participant" resolution, which is broken for the same reason.

Both are needed: the backend guard alone leaves you listed (just uninvitable); the frontend alone leaves the server unenforced.

## Summary The video-call picker lists the current user, and clicking yourself starts a call that **rings your own browser**. This is the residual root cause behind #98 — that ticket fixed the *reactivity race* (read `userIdSig` instead of the mutated `userId` string), but the filter it repaired compares two **different Keycloak claims**, so it never matches regardless of timing. ## Root cause — two ID spaces - `ChatHub.OnConnectedAsync` stores the roster entry with `Id = sid` (Keycloak **session** id) — `SpikerSoft.Contracts.SignalR/ChatHub.cs:205`. The whole of `ChatHub` is `sid`-keyed (DM participants, rooms, history). - Angular sets `chatService.userId` / `userIdSig` from `keycloak.loadUserProfile().id`, i.e. the **`sub`** user id — `_services/chat/chat.service.ts:98-99` and `:438-439`. So `u.id (sid) !== selfId (sub)` is **always true** and the filter is a no-op: - `_dialogs/video-call-picker/video-call-picker.component.ts:324-327` - `_components/chat/chat.component.ts:64-72` (same broken filter, DM list) The backend self-guard is defeated by the same skew: ```csharp // VideoCallHub.cs:187-188 if (calleeUserId == callerId) // calleeUserId is a sid, callerId is GetCurrentUserId() = sub throw new HubException("Cannot call yourself"); ``` And because #99's fix subscribes each connection to a user-group for **every** claim variant (`GetAllUserIdentifiers`, `VideoCallHub.cs:394-408`), `Clients.Group(UserGroup(calleeUserId))` delivers the invite straight back to the caller's own browser. The two fixes compose into a working self-call. ## Why the tests didn't catch it `video-call-picker.component.spec.ts:56-61` sets `userIdSig = signal("me")` alongside a `user("me")` — ids constructed to match, so it passes whatever the real claim skew is. ## Fix 1. **Backend** — `VideoCallHub.InviteUser` guards against `GetAllUserIdentifiers()` rather than `GetCurrentUserId()` alone, so a `sid`-addressed self-invite is rejected. Immune to ID-space drift (compares within one connection's own claims). 2. **Frontend** — align `chatService.userId` / `userIdSig` to the `sid` claim so it matches the roster identity `ChatHub` actually broadcasts. Every consumer of `chatService.userId` is hub-facing (`chat.component.ts:177,182,238`, `chat.service.ts:371`), so this also fixes DM "other participant" resolution, which is broken for the same reason. Both are needed: the backend guard alone leaves you listed (just uninvitable); the frontend alone leaves the server unenforced. ## Related - #98 — partial fix (race only), closed - #99 — alias user-groups, closed; interacts to make self-call actually connect

spikerj commented

2026-07-30 02:15:03 +00:00

Both halves are open — they must land together:

backend: spikerj/spikersoft-backend#511 — InviteUser guards on GetAllUserIdentifiers() instead of sub alone
angular: spikerj/spikersoft-angular#603 — ChatService keys self-identity on the sid claim

Backend alone leaves you listed (just uninvitable); angular alone leaves the server unenforced.

Verification:

Backend: dotnet build SpikerSoft.UnitTests.slnf clean, VideoCallHubTests 20/20. The new InviteUser_WithOwnSidClaim_ShouldThrow was confirmed to fail against the old guard, so it's real coverage, not a test pinned to current behavior.
Angular: full nx test spikersoft — 3489 passed / 6 skipped. Picker + ChatService specs rewritten to sid-shaped ids; the old ones used a generic "me" on both sides of the comparison, which is why they passed while prod was broken.

Not manually QA'd against a live Keycloak session — the claim analysis comes from the hub source (ChatHub hard-requires sid to register a connection, so anyone in the roster has one). Worth a click-through after deploy.

Both halves are open — **they must land together**: - backend: spikerj/spikersoft-backend#511 — `InviteUser` guards on `GetAllUserIdentifiers()` instead of `sub` alone - angular: spikerj/spikersoft-angular#603 — `ChatService` keys self-identity on the `sid` claim Backend alone leaves you listed (just uninvitable); angular alone leaves the server unenforced. Verification: - Backend: `dotnet build SpikerSoft.UnitTests.slnf` clean, `VideoCallHubTests` 20/20. The new `InviteUser_WithOwnSidClaim_ShouldThrow` was confirmed to **fail against the old guard**, so it's real coverage, not a test pinned to current behavior. - Angular: full `nx test spikersoft` — 3489 passed / 6 skipped. Picker + `ChatService` specs rewritten to sid-shaped ids; the old ones used a generic `"me"` on both sides of the comparison, which is why they passed while prod was broken. Not manually QA'd against a live Keycloak session — the claim analysis comes from the hub source (`ChatHub` hard-requires `sid` to register a connection, so anyone in the roster has one). Worth a click-through after deploy.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#898

[Bug] You still see (and can call) yourself in the video-call picker — self-filter compares sub against ChatHub's sid #898

Summary

Root cause — two ID spaces

Why the tests didn't catch it

Fix

Related

[Bug] You still see (and can call) yourself in the video-call picker — self-filter compares `sub` against ChatHub's `sid` #898