DEV Community

RadcliffBarrett4718
RadcliffBarrett4718

Posted on

WebRTC Delivery Receipts: 5 Realtime Idempotent Security Patterns for Chat Escalations

#realtime #webrtc #security

Short answer: for realtime idempotent publishes in customer support chat, use five security controls: issue a short-lived, scoped room token from a trusted service, make the publish receipt durable before a customer-visible message or video invite is fanned out, and measure presence from expiring observations instead of a socket's apparent existence.

Control or design Pick this when Trade-off
Durable receipt with a unique key A reply or room invite must appear once after retries Needs a database write and retention policy
Transactional outbox Chat history and video-room events need one audit trail Adds a worker and a little delivery delay
Expiring presence observations The decision depends on whether an agent is really available Presence can be briefly stale between heartbeats
Per-room scoped token Customers can escalate a chat into a video room Token issuance and revocation become part of the workflow
In-memory dedupe A single-process prototype has disposable events It loses protection during restart or horizontal scaling

The table is a field guide, not a ranking. For a support queue, I start with a receipt keyed by tenant, conversation, actor, and client-generated request ID. The receipt is the narrow waist between an untrusted browser and the realtime transport. When the same request arrives twice, the service returns the first outcome rather than creating a second message or room invite.

That distinction matters during an escalation. A customer may click “Join video” while an agent's tab is reconnecting, and a mobile client may retry after a timeout even though the server accepted the first request. Presence accuracy, not raw publish speed, is the decision axis: the system must know which actor was authorized and which observation was current when it issued the room token. In one particularly awkward failure mode, the browser receives a timeout after the database commit, retries with the same ID, and then opens a second video room because the first implementation checked only the transport response. The duplicate room is confusing for the customer, expensive to clean up, and invisible if logs record only HTTP status. Keeping the receipt and room identifier together turns that race into a normal read. The retry returns the original room token metadata, while the audit trail shows exactly when the agent's presence was observed and which policy version made the decision.

Ship once.

How can idempotent security controls protect realtime customer support chat?

Use five gates in order. Authentication identifies the account. Authorization binds that account to one tenant, conversation, and escalation policy. Schema validation limits text, metadata, and request-ID size. Idempotency binds the accepted payload to a durable receipt. Observability records every decision and its reason. Only an accepted receipt may enter the fan-out path.

Keep the request ID outside the message body. A browser can reuse an ID, change the body, or aim it at another conversation. Store a digest of the authorized payload beside the ID. A repeated tuple with the same digest returns the saved result. A repeated tuple with a different digest is a conflict and should not publish anything.

For room creation, include the room purpose and participant scope in that digest. A token for tenant-a/conversation-42 must not become a token for another tenant because a client copied a URL. The token subject should identify the actor, and its expiry should be shorter than the expected support session. Revocation is still needed when an agent leaves the queue or a ticket changes ownership.

Presence needs its own record. Write a heartbeat observation with an expiry, sequence number, and server timestamp; then make the room-issuance decision against that record. A green badge is a hint, not proof of delivery. Sleeping browser tabs, mobile radio power saving, and a saturated laptop can all delay a heartbeat.

What does a trusted publish path look like for chat-to-video escalation?

The path is easier to debug when each state has one owner:

received -> authorized -> reserved -> published -> acknowledged

rejected is terminal. reserved means the receipt and outbox row exist, not that a client has seen anything.

Here is a compact TypeScript sketch. The storage adapter is expected to enforce a unique constraint on the four-part key and to return the existing row on a duplicate insert. The transport endpoint is intentionally generic; keep its credential on the server.

type Escalation = {
  tenantId: string;
  conversationId: string;
  actorId: string;
  requestId: string;
  text: string;
  wantsVideo: boolean;
};

export async function acceptEscalation(input: Escalation, accessToken: string) {
  const claims = await verifyAccessToken(accessToken);
  if (claims.tenantId !== input.tenantId || claims.subject !== input.actorId) {
    throw new Error("forbidden");
  }
  if (!/^[A-Za-z0-9_-]{12,100}$/.test(input.requestId)) {
    throw new Error("invalid_request_id");
  }
  if (input.text.length > 4000) throw new Error("message_too_large");

  const presence = await presenceStore.current(input.tenantId, input.actorId);
  if (!presence || presence.expiresAt <= Date.now()) {
    throw new Error("agent_not_present");
  }

  const digest = await sha256(JSON.stringify({
    conversationId: input.conversationId,
    text: input.text,
    wantsVideo: input.wantsVideo,
  }));
  const receipt = await receipts.reserve({
    tenantId: input.tenantId,
    conversationId: input.conversationId,
    actorId: input.actorId,
    requestId: input.requestId,
    digest,
  });
  if (receipt.kind === "existing" && receipt.digest !== digest) {
    throw new Error("idempotency_conflict");
  }
  if (receipt.kind === "existing") return receipt.result;

  const room = input.wantsVideo
    ? await rooms.create({ tenantId: input.tenantId, conversationId: input.conversationId })
    : undefined;
  const payload = {
    receiptId: receipt.id,
    text: input.text,
    roomToken: room ? await issueScopedRoomToken(room.id, input.actorId) : undefined,
  };
  await outbox.append({ topic: "support.escalation", payload });
  await receipts.markPublished(receipt.id, payload);
  return payload;
}
Enter fullscreen mode Exit fullscreen mode

The important ordering is the reservation before the side effect. If the process stops after rooms.create, a retry must consult the receipt and outbox, not blindly create another room. A worker can reconcile a reserved row with the append-only event log, then mark it published or rejected with a reason. That read is slower than a second create call. It is also what keeps an agent from seeing two identical invites.

Do not put a provider secret in a browser bundle, mobile binary, or source map. The browser receives a scoped, expiring token and the minimum room metadata it needs. The service checks the token subject and conversation binding on every privileged action. WebRTC supplies peer-connection and media primitives; your receipt, authorization, and audit policy remain application responsibilities.

Which signals prove that retries and presence are behaving?

Log one structured decision per request. Include tenant, conversation, actor, request ID, payload digest, policy version, presence observation timestamp, receipt state, and latency. Never log the raw access token or message text by default. A digest lets an incident responder distinguish a harmless retry from a replay with altered content.

Metrics should describe ratios and age, not just exceptions. Track duplicate-request conflicts, authorization rejects, expired-presence rejects, receipt age over 30 seconds, publish latency, and the gap between published and client acknowledgement. A single 401 can be normal. A sudden conflict spike often points to a client retry loop or a stolen request ID.

For reconnects, send the last acknowledged receipt ID and the client's observed sequence number. The server replays missed events from the conversation stream, then emits a fresh presence observation. Do not infer presence from a websocket that happens to be open. Your mileage may vary on the exact presence TTL; choose it from the longest expected reconnect window, then test clock skew and revocation in staging.

I keep a red-team test that submits the same request ID with two bodies. The first body must produce one receipt; the second must produce idempotency_conflict and zero additional fan-out events. Another test expires the agent heartbeat between authorization and room issuance. It should fail closed, with an audit record that explains which observation was stale.

Where does this design stop being a good fit?

The catch is operational weight. Durable receipts, an outbox, token rotation, and audit retention add schema work and a little latency. This design is not suitable for disposable telemetry where duplicate events have no user-visible effect; use a lossy stream there. Stick with an in-memory map only for a one-process prototype, and replace it before adding a second instance.

It also does not make an untrusted client trustworthy. Rate limits per actor and conversation, content controls, maximum key length, and tenant isolation still matter. If your chat product cannot issue per-room scopes or revoke sessions, keep video escalation behind a separate authorization service instead of stretching a broad chat token.

The practical rule is narrow: reserve once, publish from the reservation, and let presence decide whether a room can be issued now. Test the crash windows explicitly. Five controls give the team a shared vocabulary, but threat modeling should decide their exact values.

References

Top comments (0)