fix(client): use correct OAuth credentials and handle gzip responses#15
Open
gee-m wants to merge 3 commits intosteipete:mainfrom
Open
fix(client): use correct OAuth credentials and handle gzip responses#15gee-m wants to merge 3 commits intosteipete:mainfrom
gee-m wants to merge 3 commits intosteipete:mainfrom
Conversation
Two bugs in the API client: 1. authTokenEndpoint() hardcoded client_id as "sleep-client" with an empty client_secret instead of using the actual app credentials (c.ClientID / c.ClientSecret). This causes a 400 from the auth server, which then falls through to legacy login and triggers rate limiting (429) — making the CLI permanently unusable. 2. do() sends Accept-Encoding: gzip but never decompresses the response body, causing JSON decode errors (invalid character 0x1f) on endpoints that return gzipped responses.
- TestAuthTokenEndpointUsesConfiguredCredentials: verifies New() defaults to the app credentials (not 'sleep-client') and that custom creds pass through - TestDoHandlesGzipResponse: verifies gzip Content-Encoding is decompressed - TestDoHandlesPlainResponse: verifies plain responses still work
…in tests The credential test only verified that New() assigns struct fields — it couldn't actually test that authTokenEndpoint() sends the right values in the HTTP request because authURL is a package-level const pointing at the real Eight Sleep server. The captured variables were never asserted. The plain response test duplicated coverage already provided by TestRequireUserFilledAutomatically. The gzip test is the only one that exercises a real code path we changed (Content-Encoding: gzip decompression in do()), so keep that.
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.
Problem
Two bugs in the API client that make
eightctlpermanently fail with 429 errors:1. Wrong OAuth credentials in token endpoint
authTokenEndpoint()hardcodesclient_id: "sleep-client"with an emptyclient_secretinstead of using the actual app credentials (c.ClientID/c.ClientSecret— the ones extracted from the Eight Sleep Android app).The auth server rejects this with a 400 (Joi validation fails on the empty secret), which falls through to
authLegacyLogin(). By that point, the rate limiter has already been tripped → permanent 429 loop.2. Gzip responses not decompressed
do()sendsAccept-Encoding: gzipbut never decompresses the response body, causing:(
0x1fis the gzip magic byte.)Fix
c.ClientIDandc.ClientSecretin the token endpoint payloadContent-Encoding: gzipis presentTested against a live Pod 5 — both auth and API calls work correctly after the fix.
Fixes #7, fixes #8, fixes #12