- Shipped
- September 5, 2026 at 2:05 AM UTC
- Author
- Kamo
- Commit
- 222a63f
An org pasted its RingCentral app's credentials JSON — the {"clientId": …, "clientSecret": …, "server": …} blob the developer console shows on the same page as the JWT — into the Service user JWT box. Nothing objected. The value was stored, the settings page showed a green "Credentials complete" chip, and RingCentral answered every token exchange with 400 invalid_request / OAU-331 "Unparseable assertion" — which Kamo relayed as "create a new JWT and paste it in again", the one instruction that leads straight back to the same paste. isConfigured() asked only whether the JWT box was non-empty, so the chip and the sync sweep disagreed about the very same row. - RingCentralJwtFormat judges the shape only: three dot-separated base64url segments. A well-formed JWT is still RingCentral's to accept or refuse, since a false rejection would lock an operator out of a credential that works. - The value is refused where it is typed, so it never reaches the row. Only a newly submitted JWT is judged — an update sending "***" means "keep the stored one", and an instance already holding a bad JWT must still be able to save its name, its main number, or the switch that turns it off. - isConfigured(), require() and the member-JWT validation path all apply it, and each names what appears to have been pasted rather than repeating RingCentral's opaque answer. OAU-331 coming back from RingCentral now says so too, for credentials stored before this change. Also: **************** swallowed **************** and returned an empty list. InstanceSyncService forgives only **************** so it read that as an authoritative empty account — logging "InstanceSync OK … ext=0 users=0 dev=0", clearing last_sync_error, and soft-deleting every cached extension, user and device to UNKNOWN. A rejected credential now fails the sweep, so an expired JWT can no longer erase an org's phone inventory and report success for it.