Skip to content

fix: remove Authorization header for unauthenticated payment methods …#9060

Merged
meltingice1337 merged 4 commits into
mainfrom
fix/TRAM-3502-remove-auth-payments
Jun 11, 2026
Merged

fix: remove Authorization header for unauthenticated payment methods …#9060
meltingice1337 merged 4 commits into
mainfrom
fix/TRAM-3502-remove-auth-payments

Conversation

@meltingice1337

@meltingice1337 meltingice1337 commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Explanation

RampsService.getPaymentMethods was recently changed (in #8888, still unreleased) to send an Authorization: Bearer <token> header, sourcing the token from AuthenticationController:getBearerToken. In practice, the payment-methods was changed to be called before the user signed into metamask.

Requiring a bearer token there is problematic because AuthenticationController.getBearerToken is not a passive read:

  • If the wallet is locked, it throws (getBearerToken - unable to proceed, wallet is locked).
  • If the wallet is unlocked but not signed in, it falls through to getAccessToken, which performs a full SRP sign-in (network round-trip + SIWE/SRP signing) as a side effect.

So fetching a payment-methods catalog could either fail outright or silently sign the user in — neither of which should happen just to render a list of payment options.

This PR scopes bearer-token auth back to the endpoints that genuinely need it. getPaymentMethods is now fetched as an unauthenticated request (matching the existing pattern used by getGeolocation, getProviders, etc.), while getQuotes and getBuyWidgetUrl keep their Authorization headers since they create user-bound orders/widgets.

Changes:

  • RampsService.getPaymentMethods — removed the #getRequestHeaders() call and now passes no headers to fetch. The private #getRequestHeaders helper is unchanged and still used by getQuotes and getBuyWidgetUrl.
  • Tests — replaced the three payment-methods auth tests with negative assertions (does not request a bearer token, does not send an Authorization header) mirroring the existing getGeolocation auth-scope tests. The "rejects when the bearer token cannot be retrieved" test was removed as no longer applicable.
  • Changelog — kept the original feat: add bearer token authorization to RampsService payments & quotes #8888 entry intact and added a separate Changed entry documenting that getPaymentMethods no longer sends an Authorization header.

References

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Changes when ramps auth runs and could fail if the API still required a token for payment methods; intended to stop locked-wallet failures and accidental sign-in from catalog loads.

Overview
Reverts bearer-token auth on RampsService.getPaymentMethods so the regions/payments catalog can load before sign-in. The method no longer calls #getRequestHeaders() or sends an Authorization header on fetch, aligning it with other public catalog calls (e.g. geolocation/providers). getQuotes and getBuyWidgetUrl still use authenticated headers.

Tests now assert payment-methods requests do not call getBearerToken and do not send Authorization, and drop the case where a missing token blocked the HTTP call. The ramps-controller changelog records this under Changed.

Reviewed by Cursor Bugbot for commit 082a6c3. Bugbot is set up for automated code reviews on this repo. Configure here.

@meltingice1337 meltingice1337 requested review from a team as code owners June 9, 2026 13:18
…auth-payments

# Conflicts:
#	packages/ramps-controller/CHANGELOG.md
@amitabh94

Copy link
Copy Markdown
Contributor

Should we move the payment call after sign in ?

@meltingice1337

Copy link
Copy Markdown
Contributor Author

Should we move the payment call after sign in ?

I would assume there is a reason the payments call is made at metamask open. Since it is not part of the abuse flow and doesn't return anything relevant, we can leave it unauthenticated.

…auth-payments

# Conflicts:
#	packages/ramps-controller/CHANGELOG.md
@meltingice1337 meltingice1337 added this pull request to the merge queue Jun 11, 2026
Merged via the queue into main with commit 04b6ef3 Jun 11, 2026
372 checks passed
@meltingice1337 meltingice1337 deleted the fix/TRAM-3502-remove-auth-payments branch June 11, 2026 11:49
@meltingice1337 meltingice1337 mentioned this pull request Jun 12, 2026
4 tasks
pull Bot pushed a commit to dmrazzy/core that referenced this pull request Jun 12, 2026
## Explanation

This is the release PR for `1038.0.0`, generated by
`create-release-branch`. It bumps the monorepo version from `1037.0.0`
to `1038.0.0` and releases a single package:
`@metamask/ramps-controller` `14.1.1` → `14.2.0`. The release moves the
entries that had accumulated under `[Unreleased]` into a new `[14.2.0]`
section in the package's changelog.

`@metamask/ramps-controller@14.2.0` includes the following:

- **Changed** — `RampsService.getQuotes` now sends an `Authorization:
Bearer <token>` header, sourcing the token from
`AuthenticationController:getBearerToken` (already a required messenger
action since `14.0.0`); the call throws if no token is available (e.g.
the wallet is locked or the user is signed out)
([MetaMask#8888](MetaMask#8888)). This is the
notable change driving the version bump: `getQuotes` previously made an
unauthenticated request and now requires a bearer token, so consumers
should review their sign-in state before upgrading.
- **Changed** — Bump `@metamask/controller-utils` from `^12.1.0` to
`^12.2.0` ([MetaMask#9058](MetaMask#9058),
[MetaMask#9083](MetaMask#9083)).

Note on `getPaymentMethods`: within this unreleased window, auth was
added to `getPaymentMethods` (MetaMask#8888) and then removed again (MetaMask#9060) so
that payment methods can be fetched before sign-in. Because that change
was reverted before shipping, it nets to no consumer-facing change and
is intentionally omitted from the changelog per the project's "omit
reverted changes" guideline.

This is a minor release (`14.2.0`). It contains no breaking changes; the
version is bumped to minor — rather than patch — to surface the
`getQuotes` authentication behavior change, which alters how an existing
method makes its request even though the public interface is unchanged.
As part of cutting the release, the in-monorepo consumer
`@metamask/transaction-pay-controller` has its dependency on
`@metamask/ramps-controller` bumped to `^14.2.0`; this is a mechanical
version bump required by the release tooling and does not change
`transaction-pay-controller`'s behavior.

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

Release PR generated by `create-release-branch`; see
`docs/processes/releasing.md`. `@metamask/ramps-controller` was bumped
to a minor (`14.2.0`) rather than a patch in response to review feedback
that the `getQuotes` authentication change is a notable behavior change
to an existing method.

## Checklist

- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md)
- [ ] I've introduced [breaking
changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md)
in this PR and have prepared draft pull requests for clients and
consumer packages to resolve them

---------

Co-authored-by: Darius Costolas <10818970+meltingice1337@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.

2 participants