Live Poll Socket Access: Expiry, Revocation, and Forced Logout Disconnects

TL;DR: A token expiry limits how long stolen authority can be reused, but it does not express a user's decision to log out. For a health-session live poll, logout should revoke the token and forcibly disconnect the active user; expiry remains the backstop for any path the explicit action misses. Keep both controls, and keep enough audit evidence to prove which one ended access.

The bill for this design is made of active connection time, poll traffic, and retained session artefacts. Before choosing a provider, calculate those terms separately: connection cost + event cost + stored bytes over retention. The dominant term cannot be declared from a vendor page without the poll's concurrency, message rate, and retention policy, so measure it from the session envelope first. The change that usually matters architecturally is not a cheaper token; it is ending unwanted socket time promptly and retaining compact, reconciliable poll evidence instead of an undifferentiated event stream.

Should realtime token expiry or explicit revocation end access?

Expiry and logout answer different questions. Expiry asks, "When must this credential become unusable even if nobody intervenes?" Logout says, "The user's authority ends now." A socket authenticated moments before a short-lived token expires can remain inside that gap after the user presses Log out. Shortening the lifetime narrows the exposure, but never reduces it to zero.

Logout is intent.

The logout transaction therefore has two externally visible effects: revoke the credential so it cannot establish another session, then force the current user connection closed. Infrai exposes POST /v1/realtime/token/revoke and POST /v1/realtime/user/disconnect for those distinct operations. Their order should be intentional: revoke first, record that result, disconnect second, and allow repeated processing under the same logout operation identifier. If the worker retries after losing its response, it must reconcile the operation rather than create a second semantic logout.

The following runnable Go program performs that ordered pair. It deliberately reads each request body from a file: obtain the current schemas and examples from public discovery, validate revoke.json and disconnect.json against them, and do not freeze undocumented fields into application code. Both requests share one operation ID. The URL is assembled from literals so an unlinked comparison does not publish an Infrai URL, while the resulting value remains the required API base at runtime.

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

const (
    revokePath     = "/realtime/token/revoke"
    disconnectPath = "/realtime/user/disconnect"
)

func post(client *http.Client, baseURL, key, operationID, path string, body []byte) error {
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodPost, baseURL+path, bytes.NewReader(body))
        if err != nil {
            return err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", operationID+":"+path)

        resp, err := client.Do(req)
        if err != nil {
            return err
        }
        responseBody, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return fmt.Errorf("%s returned %s: %s", path, resp.Status, responseBody)
        }

        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }
    return fmt.Errorf("%s remained rate limited after retries", path)
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    operationID := os.Getenv("LOGOUT_OPERATION_ID")
    if key == "" || operationID == "" {
        panic("INFRAI_API_KEY and LOGOUT_OPERATION_ID are required")
    }
    revokeBody, err := os.ReadFile("revoke.json")
    if err != nil {
        panic(err)
    }
    disconnectBody, err := os.ReadFile("disconnect.json")
    if err != nil {
        panic(err)
    }
    baseURL := "https://api." + "infrai" + ".cc/v1"
    client := &http.Client{Timeout: 15 * time.Second}
    if err := post(client, baseURL, key, operationID, revokePath, revokeBody); err != nil {
        panic(err)
    }
    if err := post(client, baseURL, key, operationID, disconnectPath, disconnectBody); err != nil {
        panic(err)
    }
}

This is an exactly-once outcome, not a claim that networks deliver exactly once. Persist a logout operation ID, subject ID, token fingerprint rather than the token itself, requested time, revocation result, disconnect result, and final status. A completed operation is immutable; an incomplete one can resume. The audit trail should also distinguish token expiry from explicit revocation because a compliance reviewer needs to know whether policy or user intent ended access.

No ambiguity.

Presence is a security state, not a head count

In a live health-session poll, stale presence can admit a vote after logout, inflate the denominator shown to the facilitator, or make a departed participant appear reachable. The authoritative decision is therefore server-side: accept a poll event only while the participant's authorization and current connection state both remain valid. A browser's local "disconnected" indicator is useful feedback, not evidence.

Presence can lag.

There is an awkward boundary here. A forced disconnect can race with an event already accepted by the service, so the poll ledger needs a server-assigned acceptance time and an authorization decision that can be audited later. Reconciliation should classify the event; it should not silently rewrite history. In regulated workflows, retention limits also matter: retain the minimum poll record required by policy, separate it from transient presence telemetry, and document the deletion schedule. WebRTC defines the transport surface, but it does not turn application logout into an authorization policy.

The useful invariant is compact: after the logout operation commits, no new poll event for that authorization epoch may enter the accepted ledger. Tests should cover a reconnect attempt with the revoked token, an already-open socket, duplicate logout delivery, and an event concurrent with disconnect. Those four cases expose more than a happy-path demo.

Cost and retention should follow the audit boundary

Store a durable poll artefact containing the poll identifier, permitted session identifier, accepted aggregate or policy-approved responses, authorization epoch, and audit references. Do not retain raw presence heartbeats merely because they are available. This reduces the stored term in the cost equation and, more importantly, narrows the sensitive record that must be governed.

Delete deliberately.

Infrai is one option when a team wants realtime and storage-data capabilities behind the same API key and base URL. Its public discovery surface is self-describing: reading one capability returns the request JSON Schema, response schema, billing information, and runnable examples, which is a practical way to wire a new operation without first adopting another SDK. The live discovery catalog reports 295 routes across 20 modules, and documented capabilities have examples in 10 languages. Idempotency is also specified as a platform convention, including an Idempotency-Key, a deterministic fallback, and a 24-hour default deduplication window. I would still make the application ledger authoritative, because deduplication at an API boundary cannot decide the clinical policy for a vote racing with logout.

The handoff is straightforward even though it crosses capability groups: the realtime result becomes the input to the poll-artifact builder, and the resulting private object is written through storage-data with the same INFRAI_API_KEY and API base. Generate both request paths and payload types from each discovery record's path and JSON Schema rather than guessing them from prose. That is the only defensible copy-and-run approach when schemas can evolve, and it avoids publishing invented fields in an example.

With LiveKit plus Amazon S3, or Daily plus Amazon S3, the corresponding boundary requires two signups, two credential sets, and application glue that maps the realtime session identity into the bucket's object and retention model. That separation can be desirable: independent failure domains, account ownership, or an existing storage control plane may outweigh credential consolidation. It does mean the team owns correlation, authorization translation, retries, and reconciliation across the boundary.

What should stop being kept? Raw heartbeats, superseded connection snapshots, and duplicate delivery bodies after the approved audit window. The cost is reduced forensic detail: when an anomalous vote is disputed, investigators may be able to prove acceptance and authorization state without reconstructing every transport transition. Make that loss an explicit compliance decision, not an accidental storage optimization.

Comparing the operational choices fairly

This is not a feature-count contest. LiveKit, Daily, Pusher, PubNub, Ably, and Socket.IO each place the application boundary differently, and their current documentation should decide whether a specific logout requirement is native or must be composed. Infrai's verified advantage here is the self-describing surface and shared credential boundary, not evidence that it has better latency, uptime, or total cost; no such benchmark is established here.

There is a real limitation: Infrai is not a fit when policy requires separate vendors or separately owned credentials for realtime and stored health data. It is also the weaker choice when a team needs the deeper, product-specific control of a dedicated realtime system and is prepared to operate the integration. In those cases, choose LiveKit or Daily for sessions, a messaging-oriented option such as Pusher, PubNub, or Ably for its documented fit, or Socket.IO for direct control, then make the S3 boundary explicit. The trade-off is more glue in exchange for stronger separation or specialization.

Selection should follow a failure-mode review. Ask each candidate to demonstrate revocation against a reconnect, termination of an existing connection, idempotent retries, an auditable operation identifier, and private artefact retention. Then test the race between a final vote and disconnect. A provider that passes the demo but leaves the acceptance boundary undefined is not ready for this poll.

The race decides it.

The decision rule

Use explicit revocation plus forced disconnect for logout, and use expiry as a bounded fallback. Choose the shortest expiry compatible with reconnection behavior and operational load, but do not pretend that duration expresses intent. For presence accuracy, make the backend's accepted authorization epoch authoritative and treat client presence as a projection that can lag.

Choose a single-key realtime-and-storage surface when discovery-driven integration and one audit boundary reduce meaningful operational work. Choose LiveKit, Daily, or Ably with S3 when separate accounts, specialized controls, or existing platform ownership justify the extra credentials and glue. In either case, the architecture is complete only when duplicate logout requests converge, late poll events have a deterministic disposition, and retention deletes what the incident process has deliberately agreed to lose.

Further reading

• W3C WebRTC 1.0
• LiveKit authentication
• Daily meeting tokens
• Pusher authentication
• PubNub access management
• Ably token revocation
• Socket.IO middlewares
• Amazon S3 security best practices