Ignore API load balancer stickiness cookies - #1177
Conversation
|
hmm looks like the 403s were from ELB, so maybe this isn't the right fix EDIT: updated to handle the ALB cookie issues |
c1f9193 to
99f844c
Compare
matthewgrossman
changed the title
99f844c to
c9764fe
Compare
matthewgrossman
changed the title
c9764fe to
eef8945
Compare
| kwargs["headers"]["Authorization"] = f"Bearer {self.access_token}" | ||
|
|
||
| if url_base == API_URL_BASE: | ||
| cookies = dict(kwargs.get("cookies") or {}) |
There was a problem hiding this comment.
Good call. Replaced dict(...) with dictionary unpacking; this still creates a shallow copy so a caller-provided cookie mapping is not mutated.
There was a problem hiding this comment.
that was the key idea to not mutate that kwarg, so it was just making a new dict. Honestly mutating the kwarg is probably fine but I was just being defensive with it; happy to remove if you think it's unnecessary
Signed-off-by: Matthew Grossman <matthewryangrossman@gmail.com>
eef8945 to
7b7c96f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #1177 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 16 16
Lines 1024 1027 +3
=========================================
+ Hits 1024 1027 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 participants
Describe what the PR does:
This issue was observed in Home Assistant after the SimpliSafe integration had run normally for several days. Subscription polling and control requests then began returning 403 every 30 seconds, leaving entities unavailable until the integration was restarted. Home Assistant supplies a long-lived
aiohttp.ClientSession, so cookies set by the SimpliSafe API persist across requests and token refreshes.SimpliSafe API responses set the AWS load-balancer stickiness cookies
AWSALBandAWSALBCORS. Direct probes isolated specific stored cookie values as the cause of the failure: requests using the same fresh access token and headers returned an ALB-branded HTML 403 with those values and 200 without them. The 403 response was:This also explains why refreshing the access token alone did not recover the integration, while restarting it appeared to clear the condition.
This change masks both cookies with empty per-request values for
api.simplisafe.com. Explicit request cookies override values from the session cookie jar, so the fix does not modify the caller-owned session or affect requests to other hosts. Existing token refresh and HTTP error handling remain unchanged.Does this fix a specific issue?
No existing issue found.
Checklist:
README.mdwith any new documentation. No public API or configuration changed, so no documentation update is needed.The regression test adds the problematic cookies to the session, verifies that the outgoing API request masks them, and exercises the existing 401 refresh and successful retry flow.
Validation:
poetry run pytest --cov simplipy tests— 94 passed, 100% coveragepoetry run mypy simplipy testsSKIP=no-commit-to-branch,pytest poetry run pre-commit run --all-files** Some commentary **
I'm surprised more things in HA don't break with a weeks+ old aiohttp client honestly. This only started happening to me recently, so I'm guessing this is some simplisafe load balancer change they made? If the simplisafe requests were all properly issueing updated
set-cookieheaders, then I wouldnt' think this would be an issue.