Skip to content

Fix critical auth: send access-token header instead of Authorization: Bearer#3

Merged
pimfeltkamp merged 3 commits intomainfrom
fix-auth-header-access-token
Apr 28, 2026
Merged

Fix critical auth: send access-token header instead of Authorization: Bearer#3
pimfeltkamp merged 3 commits intomainfrom
fix-auth-header-access-token

Conversation

@pimfeltkamp
Copy link
Copy Markdown
Contributor

Tracking: cryptohopper-resources#9. Sister PRs landing for Node/Python/Go/Rust/PHP/Dart/Swift in this same iter.

The transport sent Authorization: Bearer <token> which the AWS API Gateway in front of api.cryptohopper.com/v1/* rejects with 405 Missing Authentication Token — the gateway routes Authorization to a SigV4 parser. The Public API v1 uses access-token: <token> instead. Confirmed via the live API docs and the legacy iOS/Android SDKs.

Changes:

No public-API change.

Critical: every authenticated request was being rejected by the
AWS API Gateway in front of api.cryptohopper.com/v1/*. Switching to
access-token: <token> as documented in the official Cryptohopper
API docs and used by the legacy iOS/Android SDKs.

Bump to 0.1.0.pre.alpha.2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Exchange section claimed the endpoints accepted anonymous calls.
The auth-header fix in this PR establishes that EVERY endpoint on
api.cryptohopper.com/v1/* requires a real token (the AWS API
Gateway has no anonymous routes), so the README label was
misleading. Replaces it with a comment that matches reality.
@pimfeltkamp
Copy link
Copy Markdown
Contributor Author

Pushed a small follow-up commit (Drop ... README claim ...) that strikes the matching (public, no auth) / (public — no auth required) claim from the README. Same bug surface as this PR — the auth fix establishes that every endpoint requires a real token, so the README label was misleading. No re-review needed beyond skimming the +1/-1 (or +2/-2) README diff.

…Association

RuboCop's `Lint/AmbiguousBlockAssociation` flagged the `.with { … }`
block — without explicit parens, Ruby's parser binds the block to the
inner method, not the outer `expect(…).to(…)`. RuboCop is conservative
here: the binding actually was correct, but the warning is still
correctable. Wrapping the matcher in parens makes the association
explicit and lets `--fail-level W` pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@pimfeltkamp pimfeltkamp merged commit 318831d into main Apr 28, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant