Do not clear the configured OAuth Client ID on a token mismatch (#712) - #713
Open
einanderson wants to merge 2 commits into
Open
Do not clear the configured OAuth Client ID on a token mismatch (#712)#713einanderson wants to merge 2 commits into
einanderson wants to merge 2 commits into
Conversation
When the stored token belonged to the bundled Client-ID while the user had configured their own, valid_token() cleared the configured Client-ID and fell back to the bundled one. The bundled Client-ID is confidential and cannot refresh tokens, so the user was stranded: every login died ~1h later, and re-entering the Client-ID triggered the very same wipe again. Following the README this was the normal path, not an edge case: log in first, register a public app and enter its Client-ID afterwards -> the next API call sees the mismatch and wipes the setting that was just entered. Discard the stale token instead and ask for a new login; the configured Client-ID is the user's deliberate setting and stays untouched. The README now puts the Client-ID before the login, so the mismatch does not happen in the first place, and points existing users at a single re-login. Fixes anxdpanic#712 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A token is only valid for the Client-ID it was issued for. Entering a Client-ID after logging in therefore leaves a stale token behind, which only surfaces on the next API call as a "Client id mismatch" dialog and a manual re-login. That ordering trap is what made issue anxdpanic#712 so easy to walk into. Discard the token as soon as the setting changes, so the order in which the user logs in and configures their Client-ID no longer matters. Clearing the store mirrors empty values back into the Kodi settings, which fires onSettingsChanged again; remembering the new Client-ID before clearing makes the second call a no-op. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the loop reported in #712: the add-on clears the OAuth Client ID the user configured.
What happens
Twitch.valid_token()compares the Client ID the token was issued for with the configured one.On a mismatch it called
utils.clear_client_id()— deleting the user's setting and falling backto the bundled Client ID, which Twitch treats as a confidential client and which therefore cannot
refresh. Every fresh login then died again after about an hour.
It is a stable loop, because the documented order makes users walk straight into it: the README
said log in first, enter your own Client ID afterwards — which produces exactly that mismatch, and
every repair attempt triggers the same wipe. The reporter's dialog quote "Client id mismatch /
Press OK to resolve" is the wipe being confirmed.
The change
Discard the stale token instead and ask for a new login; the configured Client ID is left
alone.
clear_client_id()has no other caller and is removed. The README now puts the Client IDstep before the login.
A second commit closes the ordering trap itself: a
Monitorin the service discards the storedtoken as soon as
oauth_clientidchanges, so it no longer matters whether you log in first orconfigure the Client ID first. Clearing the store mirrors empty values back into the settings and
fires
onSettingsChangedagain — the remembered Client ID is updated before clearing, whichmakes that second call a no-op.
Verification
Reproduced and fixed on real hardware (Kodi 21.3, LibreELEC, Raspberry Pi 4), by writing a token
issued for the bundled Client ID and then configuring a different one:
OAuth Client-ID mismatch… mismatch, discarding the stored token<setting id="oauth_clientid" default="true" />)Two details worth knowing for anyone re-testing this: the wipe only happens after the dialog is
confirmed, and only when the stale token belongs to the bundled Client ID — a token from another
own application does not reach that branch.
onSettingsChangedwas verified to fire as well: the token is dropped 64 ms after the settingchanges, exactly once, with no re-entrancy from the settings mirror.
The reporter of #712 confirmed the workaround derived from this diagnosis (revoke token → enter
Client ID → log in) restores stable tokens for them.