fix: remove Authorization header for unauthenticated payment methods …#9060
Merged
Conversation
…ment methods in RampsService
…auth-payments # Conflicts: # packages/ramps-controller/CHANGELOG.md
Contributor
|
Should we move the payment call after sign in ? |
Contributor
Author
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
amitabh94
approved these changes
Jun 11, 2026
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>
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
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.
Explanation
RampsService.getPaymentMethodswas recently changed (in #8888, still unreleased) to send anAuthorization: Bearer <token>header, sourcing the token fromAuthenticationController: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.getBearerTokenis not a passive read:getBearerToken - unable to proceed, wallet is locked).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.
getPaymentMethodsis now fetched as an unauthenticated request (matching the existing pattern used bygetGeolocation,getProviders, etc.), whilegetQuotesandgetBuyWidgetUrlkeep theirAuthorizationheaders since they create user-bound orders/widgets.Changes:
RampsService.getPaymentMethods— removed the#getRequestHeaders()call and now passes no headers tofetch. The private#getRequestHeadershelper is unchanged and still used bygetQuotesandgetBuyWidgetUrl.does not request a bearer token,does not send an Authorization header) mirroring the existinggetGeolocationauth-scope tests. The "rejects when the bearer token cannot be retrieved" test was removed as no longer applicable.Changedentry documenting thatgetPaymentMethodsno longer sends anAuthorizationheader.References
Checklist
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.getPaymentMethodsso the regions/payments catalog can load before sign-in. The method no longer calls#getRequestHeaders()or sends anAuthorizationheader onfetch, aligning it with other public catalog calls (e.g. geolocation/providers).getQuotesandgetBuyWidgetUrlstill use authenticated headers.Tests now assert payment-methods requests do not call
getBearerTokenand do not sendAuthorization, 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.