fix: identify as akd in GSA requests to avoid HTTP 503 - #270
Closed
lonsdaleite wants to merge 2 commits into
Closed
lonsdaleite wants to merge 2 commits into
lonsdaleite wants to merge 2 commits into
Conversation
Apple's Grand Slam endpoint now refuses any request whose X-MMe-Client-Info names com.apple.dt.Xcode, answering with a bare HTTP 503 before credentials are checked. Every login therefore fails with "UnhandledProtocolError: Error response for GSA request: 503". _gsa_request already sends an akd user agent; send a matching client info string via the new BaseAnisetteProvider.client_akd property. Other requests keep using the Xcode client string.
lonsdaleite
marked this pull request as ready for review
September 13, 2026 13:36
Owner
|
Thanks a lot, this looks promising. I'll test it out either today or tomorrow. |
Owner
|
Fixed in #271, so this PR is now redundant. I chose to merge that one because it modifies the existing client string rather than adding a new one. We don't really have a reason to keep the Xcode one, in fact it would probably get confusing. But thanks for submitting a fix anyway! |
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
2 participants
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
Since early September 2026 every login fails on the very first GSA call (
"o": "init", before any password or 2FA is used):Reported in #268, #269, malmeloo/hass-FindMy#55; the same symptom is hitting other reimplementations of this protocol (dchristl/macless-haystack#245, parawanderer/OpenTagViewer#176).
Root cause
Apple's GSA edge now refuses any
POST https://gsa.apple.com/grandslam/GsService2whoseX-MMe-Client-Infoheader namescom.apple.dt.Xcode. The response is a 190-byte HTML page from the edge, not a GSA plist, and it does not depend on anisette data, account, IP or connection reuse. altstoreio/AltStore#1790 isolated the same thing by elimination (version bumps, user agent, hardware/OS portion of the header all make no difference; only the app bundle does).Reproducible with plain curl, same request, only the bundle changed:
_gsa_requestalready sendsUser-Agent: akd/1.0 ..., butX-MMe-Client-Infocame fromBaseAnisetteProvider.client, which says Xcode.Fix
BaseAnisetteProvider.client_akd: same platform string asclient, app bundlecom.apple.akd/1.0._gsa_request, so both identity headers agree. Nothing else changes; the other requests (2FA endpoints, iCloud login) keep the Xcode client string.Verification
Applied the same change to a Home Assistant 2026.9.1 install running FindMy 0.10.1 through hass-FindMy (remote
anisette-v3-server). Login went from a 503 on every attempt to reaching 2FA and completing account setup.