pubsub: let a basic-auth realtime connection enter presence for others

A realtime client built from a key alone is told clientId "*" in its
CONNECTED message. _configure_client_id opens with a branch that keeps a
configured clientId against a server wildcard, and with no clientId
configured that branch still fired, recording the clientId as validated
and None. can_assume_client_id then refused every clientId, so
presence.enter_client could never succeed on such a connection
(deviations.md I.2; RSA7b4, RTP14, RTP15). The UTS integration presence
tests and the repository's own presence suite worked around it by
configuring client_id='*'.

The branch now applies only when a clientId is configured, so with none
the client takes the wildcard as its clientId, which RSA7b4 asks for.
Because auth.client_id can now be "*", the Basic auth X-Ably-ClientId
header is taken from the configured clientId, as RSA7e2 specifies,
rather than from auth.client_id, so a wildcard the server reported is
never sent back to it as a clientId. A later authorize() on such a
client requests a wildcard token, which RSA10h asks for and the key
already permits.

This is not a breaking change. The three batch presence tests and the
two realtime integration presence tests that configured client_id='*'
as a workaround now build their clients as the specifications do.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: owenpearson

ably/pubsub/http/auth.py

@@ -377,8 +377,8 @@ def _configure_client_id(self, new_client_id):
             return
 
         # If new client ID from Ably is a wildcard, but preconfigured clientId is set,
-        # then keep the existing clientId
-        if original_client_id != '*' and new_client_id == '*':
+        # then keep the existing clientId. With none set, the wildcard is the clientId (RSA7b4)
+        if original_client_id is not None and original_client_id != '*' and new_client_id == '*':
             self.__client_id_validated = True
             self.__client_id = original_client_id
             return
@@ -404,11 +404,12 @@ def can_assume_client_id(self, assumed_client_id):
 
     async def _get_auth_headers(self):
         if self.__auth_mechanism == Auth.Method.BASIC:
-            # RSA7e2
-            if self.client_id:
+            # RSA7e2: the configured clientId, not a wildcard the server reported
+            client_id = self.auth_options.client_id
+            if client_id:
                 return {
                     'Authorization': f'Basic {self.basic_credentials}',
-                    'X-Ably-ClientId': base64.b64encode(self.client_id.encode('utf-8'))
+                    'X-Ably-ClientId': base64.b64encode(client_id.encode('utf-8'))
                 }
             return {
                 'Authorization': f'Basic {self.basic_credentials}',

test/uts/deviations.md

@@ -52,12 +52,10 @@ specification: 130 under `helpers/`, for the mocks, and 18 under `objects/helper
 the objects builders and the synced-channel mock.
 
 The 142 gated Test IDs that record SDK non-compliance — 142 tests, 144 cases — reduce to
-**61 distinct root causes**, 21 on the REST side and 40 on the realtime side. Three further
+**61 distinct root causes**, 21 on the REST side and 40 on the realtime side. Two further
 defects are recorded below with no test of their own, because the specification's test
-cannot discriminate (RTP18a), has nothing to assert against (the timezone split on
-synthesized LEAVE timestamps), or is worked around in the setup of every test that
-would otherwise trip over it (`enterClient` on an anonymous connection), so the file
-carries **64 SDK root causes** in all. The remaining 11 gated Test IDs are
+cannot discriminate (RTP18a) or has nothing to assert against (the timezone split on
+synthesized LEAVE timestamps), so the file carries **63 SDK root causes** in all. The remaining 11 gated Test IDs are
 specification faults, and reduce to 8. The objects tier records no SDK non-compliance;
 its specification faults are all corrected or worked around in tests that pass, and
 reduce to the seven candidate issues O.1–O.7, none of them filed.
@@ -1790,51 +1788,6 @@ JWT, fall with it.
 renew and retry on a token error whatever the flag says, and only then decide whether the
 final response is raised or returned.
 
-#### A basic-auth connection records its clientId as validated and `None`, so `enterClient` can never succeed — no test
-
-**Spec points:** RSA7b4, RTP14, RTP15.
-
-A client built from a full-access key alone and asked to `enter_client("user-1", …)`
-raises `AblyException: 40012 400 Unable to enter presence channel with clientId user-1 as
-it does not match the current clientId None`.
-
-The server tells such a connection `clientId: "*"` in CONNECTED, and
-`Auth._configure_client_id` (`ably/rest/auth.py:335-353`) opens with a branch that exists
-to stop a server wildcard overwriting a clientId the caller configured:
-
-```python
-if original_client_id != '*' and new_client_id == '*':
-    self.__client_id_validated = True
-    self.__client_id = original_client_id
-    return
-```
-
-With no configured clientId, `original_client_id` is `None`, `None != '*'` holds, and the
-client id is recorded as **validated and `None`**. `can_assume_client_id`
-(`auth.py:356-363`) then takes the validated path and answers `None == '*' or None ==
-assumed`, which is `False` for every clientId, so `enter_client` cannot succeed for any of
-them. The `original_client_id is None` escape in the unvalidated branch is unreachable once
-CONNECTED has arrived. The branch should apply only where a clientId was configured, and
-`__client_id` should become `'*'` otherwise, which is what RSA7b4 asks for.
-
-**Tests affected:** none, which is why this is recorded here rather than gated. The three
-`batch_presence.md` tests build their realtime client with `client_id='*'` instead, in
-`entering_client()`, with the diagnosis in its docstring — the repository's own presence
-suite carries the same workaround for the same reason, commented "Use wildcard auth for
-enterClient" (`test/ably/realtime/realtimepresence_test.py:394-396`). It is setup rather
-than subject: those tests are about `batchPresence`, and nothing they assert depends on how
-the members got there. A fix would let the setup halves be written exactly as the
-specification writes them. Both `realtime/integration` presence specifications carry the
-same workaround for the same reason — `presence_lifecycle_test.py::test_rtp4_bulk_enter_observed`
-and `presence/presence_sync_test.py::test_rtp2_sync_multiple_members` each build the client
-that enters members on behalf of others with `client_id='*'` — which makes five tests
-across two tiers that would otherwise be written as their specifications write them.
-
-This is distinct from the wildcard-clientId contradiction recorded under UTS Spec Errors,
-which is about a client that *does* configure `clientId: "*"`.
-
-**Status:** open bug, one line from a fix.
-
 #### Auth behaviour on the REST client
 
 | Spec points | Behaviour |
@@ -2933,9 +2886,9 @@ none of these shows up as a failure — which is why they are easy to lose.
 
 The five tiers above classify the realtime unit derivation; the REST unit derivation's
 candidates went upstream as [#709](https://github.com/ably/ably-python/issues/709)–[#712](https://github.com/ably/ably-python/issues/712).
-Five further defects came out of the two integration tiers, and none of them is filed; each
-keeps the label it was first given. I.1 and I.2 are tier 2 by the ranking above — an error
-where there should be none — and I.3 is tier 1 for a client that configures the option it
+Four further defects came out of the two integration tiers, and none of them is filed; each
+keeps the label it was first given. I.1 is tier 2 by the ranking above — an error where
+there should be none — and I.3 is tier 1 for a client that configures the option it
 concerns, since the call does not come back when the caller asked for it to. I.6 is tier 2
 as well; I.5 is tier 3, a presence member silently leaving the set with nothing to report it.
 
@@ -2956,15 +2909,6 @@ offset. The same expired token renews correctly through `publish()`. A fix has t
 the two meanings `raise_on_error` carries.
 `test/uts/rest/integration/auth_test.py -k rsc10`
 
-**I.2 `enterClient` cannot succeed on a basic-auth connection.** RSA7b4, RTP14, RTP15. A
-connection built from a key alone is told `clientId: "*"`, and the branch of
-`Auth._configure_client_id` (`ably/rest/auth.py:335-353`) that guards a configured clientId
-against a server wildcard fires when there is no configured clientId, recording it as
-validated and `None`. `can_assume_client_id` then refuses every clientId. One line from a
-fix, and `enter_client` is unusable without one. No test gates on it — the three tests that
-would hit it pass `client_id='*'` in setup instead, as the repository's own presence suite
-does — so it will not show up as a failure.
-
 **I.3 `httpRequestTimeout` is applied as seconds where the specification counts
 milliseconds.** TO3l4, TO3l3, RSC15l2. `ably/http/http.py:193` hands
 `(http_open_timeout, http_request_timeout)` to `httpx`, which reads seconds, so a client

test/uts/realtime/integration/presence/presence_sync_test.py

@@ -11,10 +11,6 @@
 The specification is json only — it has no `## Protocol Variants` section — so these two
 take the JSON default `sandbox_realtime_client` applies rather than the
 `use_binary_protocol` fixture.
-
-`enter_client` on a connection authenticated by key alone is refused 40012, a root cause
-recorded in [deviations.md](../../../deviations.md), so the client entering members on
-behalf of others is built with `client_id='*'`.
 """
 
 from ably.pubsub.realtime.connection import ConnectionState
@@ -61,7 +57,7 @@ async def test_rtp2_sync_multiple_members(realtime_sandbox):
     api_key = realtime_sandbox.key_str
     channel_name = 'presence-sync-multi-' + random_id()
 
-    client_a = sandbox_realtime_client(api_key, auto_connect=False, client_id='*')
+    client_a = sandbox_realtime_client(api_key, auto_connect=False)
     client_b = sandbox_realtime_client(api_key, auto_connect=False)
 
     client_a.connect()

test/uts/realtime/integration/presence_lifecycle_test.py

@@ -10,14 +10,10 @@
 attach, and a presence action is named by its lowercase wire name — `'enter'`,
 `'present'`, `'update'`, `'leave'` — which is what `set_presence` emits.
 
-Two adaptations, both of them root causes already recorded in
-[deviations.md](../../deviations.md):
-
-- Subscribing to several actions at once (RTP6b) raises `TypeError: unhashable type:
-  'list'`, because the list reaches pyee as a dict key. The one listener is registered
-  once per action instead, which is what the array form means.
-- `enter_client` on a connection authenticated by key alone is refused 40012, so the
-  client entering members on behalf of others is built with `client_id='*'`.
+One adaptation, a root cause already recorded in [deviations.md](../../deviations.md):
+subscribing to several actions at once (RTP6b) raises `TypeError: unhashable type:
+'list'`, because the list reaches pyee as a dict key. The one listener is registered once
+per action instead, which is what the array form means.
 """
 
 import asyncio
@@ -45,8 +41,7 @@ async def test_rtp4_bulk_enter_observed(realtime_sandbox, use_binary_protocol):
     api_key = realtime_sandbox.key_str
     channel_name = 'presence-bulk-' + random_id()
 
-    client_a = sandbox_realtime_client(
-        api_key, use_binary_protocol=use_binary_protocol, client_id='*')
+    client_a = sandbox_realtime_client(api_key, use_binary_protocol=use_binary_protocol)
     client_b = sandbox_realtime_client(api_key, use_binary_protocol=use_binary_protocol)
 
     client_a.connect()

test/uts/rest/integration/batch_presence_test.py

@@ -44,19 +44,13 @@ def member_for(entry, client_id):
 async def entering_client(key, use_binary_protocol):
     """A CONNECTED realtime client that may enter presence for any clientId.
 
-    The specifications build this with the full-access key alone and call
-    `enterClient` straight away. ably-python needs `client_id='*'` on top: a basic-auth
-    connection is told `clientId: "*"` by the server, and `Auth._configure_client_id`
-    answers a wildcard from the server by marking the client id validated while leaving
-    it `None` (`ably/rest/auth.py:335`), after which `can_assume_client_id` refuses every
-    id and `enter_client` raises 40012. The repository's own presence suite carries the
-    same `client_id='*'` for the same reason
-    (`test/ably/realtime/realtimepresence_test.py:396`).
+    The specifications build this with the full-access key alone, which the server
+    answers with the wildcard clientId `"*"` (RSA7b4).
 
     The connection is awaited to CONNECTED before any enter, since a presence enter on a
     connection that is still CONNECTING is queued rather than sent.
     """
-    client = sandbox_realtime_client(key, client_id='*', use_binary_protocol=use_binary_protocol)
+    client = sandbox_realtime_client(key, use_binary_protocol=use_binary_protocol)
     await await_connection_state(client, ConnectionState.CONNECTED)
     return client