where_is_waldo 0.1.14 → 0.1.15

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 55b6e1ced7f3e93a1e415bc0e28d10b15a212ad134e3108f585bea84220a1f10
-  data.tar.gz: 6c068bbd05c86ea7c6ba9b2136295f5ef17c02bd19bf9211f8b4ee59a83b17f1
+  metadata.gz: 37761c093f1789ab27d7bc83b57b965deb0039a538e1dcef1450bb8680a5328d
+  data.tar.gz: 23fe780af170d951b2b961cc6674224030f1169247a328e1e37b98a16aceb1b3
 SHA512:
-  metadata.gz: 9d96b99856186d169d3e6c97f4a032f298158ecb9e8532238c40d98a0fc7388d2a3a4eaa195417fe21064d1babc389b1c083bf85dbdfc20a33f5fb50d223d076
-  data.tar.gz: 4f0a4167858defcc5403deb7fafeac5abdb7556af91017fc1e679c952bfb39e067609ca09320353d99663106dba8f0afc9c7740c28642aff3e231057681c6b5f
+  metadata.gz: 662057f2eb1431e5b25f74ee89f6fb387748d20526325f7391112b47ce1a6c4ed10d0039341c668eeeb5e78810ed5e4e956c3076673f76c8a0c9d9a57e59c7ff
+  data.tar.gz: 220b4eaf0a42eec12e38e960afae9c0c2dc150e83cd9b2a9cb4d97efd67da9265a49eb5b0f0e399c52105f019faedd0e322cc6dfdec6c839cd2581eef7b03fc0

data/CHANGELOG.md

@@ -5,6 +5,50 @@ Notable changes to where_is_waldo. Format loosely follows
 
 ## Unreleased
 
+## 0.1.15 - 2026-11-10
+
+### Fixed
+
+- **A reconnecting client kept sending its ORIGINAL token, forever.** The auth
+  token was read once and baked into the consumer's URL string at first
+  connect. ActionCable's `Consumer` declares `get url()`, which re-runs
+  `createWebSocketURL` on every connection attempt -- so passing a string meant
+  each reconnect after a sleep, a network blip or a server restart reused the
+  token from page load.
+
+  With a short-lived access token that is a silent, permanent failure. The
+  first reconnect after expiry is rejected, every retry sends the same dead
+  token, and the client sits disconnected while looking merely idle. Presence
+  empties and anything broadcast to "online" subscribers reaches nobody. In
+  one case a tab opened a socket and the server closed it 74ms later, rejected,
+  while the application kept working and reported nothing.
+
+  `getConsumer` now hands `createConsumer` a FUNCTION, so the token is resolved
+  per attempt and a refreshed one is picked up by the next retry with no
+  intervention.
+
+### Added
+
+- **`getToken` may now return a promise.** A token provider that has to refresh
+  before it can answer could not be expressed before, because the URL callback
+  is invoked synchronously while opening a socket. An async provider is now
+  resolved in the background and its result cached for the next attempt, which
+  costs at most one refused attempt given ActionCable's backoff. Returning a
+  plain value still works exactly as before and stays synchronous.
+
+- A throwing `getToken` no longer takes the socket down with it. A storage
+  accessor can raise outright with cookies blocked or in a private window; the
+  connection now proceeds without a token and lets the server decide.
+
+### Changed
+
+- A **synchronous** `getToken` returning `null` is now taken at face value: the
+  socket connects with no token and the server decides. Previously the last
+  cached token was reused, so after a sign-out a client kept reconnecting with
+  the OLD token rather than being refused properly. A rejected or throwing
+  provider still falls back to the last known token, since those mean "could
+  not answer" rather than "there is no token".
+
 ## 0.1.14 - 2026-11-06
 
 ### Fixed

data/README.md

@@ -81,6 +81,45 @@ configureCable({
 </PresenceProvider>
 ```
 
+### `getToken` and short-lived tokens
+
+`getToken` is called **once per connection attempt**, not once at startup. That
+matters because ActionCable reconnects on its own -- after a sleep, a network
+blip, or a server restart -- and each attempt asks again. So returning the
+current token keeps a long-lived tab connected, while capturing one in a
+closure does not:
+
+```jsx
+// Good: read at call time, so a rotated token is picked up on reconnect.
+getToken: () => localStorage.getItem('token')
+
+// Broken: captured once; every reconnect resends the original token, and once
+// it expires the connection is refused for the life of the page.
+const token = localStorage.getItem('token');
+getToken: () => token
+```
+
+**It may also return a promise**, for a provider that has to refresh before it
+can answer:
+
+```jsx
+getToken: async () => (await auth.freshToken()) || null
+```
+
+The URL callback cannot await -- ActionCable invokes it synchronously while
+opening a socket -- so an async provider is resolved in the background and its
+result used from the next attempt. Given ActionCable's backoff that costs at
+most one refused attempt. The provider is not invoked again while a resolve is
+outstanding, so a reconnect storm will not fire a refresh request per attempt.
+
+Two smaller guarantees:
+
+- Returning `null` from a **synchronous** provider is taken at face value: the
+  socket connects with no token and the server decides. Use that on sign-out.
+- A provider that **throws** does not take the connection down. The last known
+  token is used instead, since a storage accessor can raise outright with
+  cookies blocked or in a private window.
+
 ```jsx
 // any component — subscribe to an event type and filter the payload yourself.
 // Auto-unsubscribes on unmount; no central handler config.

data/VERSION

@@ -1 +1 @@
-0.1.14
+0.1.15

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: where_is_waldo
 version: !ruby/object:Gem::Version
-  version: 0.1.14
+  version: 0.1.15
 platform: ruby
 authors:
 - Scott Gibson