Commit 044726b
feat: delegate AuthenticationController:getBearerToken in RampsServic… (MetaMask#30319)
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **Description**
This PR adopts the breaking messenger contract introduced in
`@metamask/ramps-controller` for
[TRAM-3502](https://consensyssoftware.atlassian.net/browse/TRAM-3502),
which moves the Buy widget API call from unauthenticated to
authenticated using a bearer token sourced from
`AuthenticationController`.
**Why:** The Buy widget endpoint on the ramps API has been gated behind
authentication. Without sending an `Authorization: Bearer <token>`
header on `getBuyWidgetUrl`, mobile users will be unable to launch the
Transak buy flow.
**What changed in core (the dependency):**
- `RampsService.getBuyWidgetUrl` now fetches a bearer token via
`AuthenticationController:getBearerToken` and sends it as an
`Authorization` header.
- `RampsServiceMessenger`'s `AllowedActions` was widened from `never` to
include `AuthenticationController:getBearerToken` — i.e. consumers (this
app) **must** delegate that action into the ramps messenger or the call
will throw.
- See the core PR for the full contract change: `<link-to-core-PR>`.
**What this PR does in mobile:**
1. Bumps `@metamask/ramps-controller` to the new major version
(currently consuming the preview build
`@metamask-previews/ramps-controller@<preview-version>` while the core
PR is in review; will switch to `^14.0.0` once published).
2. Delegates `AuthenticationController:getBearerToken` into the
`RampsServiceMessenger` at the point where the messenger is constructed
in the engine/controller-init layer.
3. Surfaces the new failure modes (wallet locked / user signed out /
token fetch failure) to the Buy entry points so the user gets a usable
error rather than an unhandled rejection.
## **Changelog**
CHANGELOG entry: null
<!-- This PR has no end-user-visible UI change on the happy path. The
Buy flow behaves identically when the user is signed in; the only
user-visible difference is improved error handling on signed-out /
locked states, which is captured in the relevant feature changelog by
the entry-point change, not here. If release engineering prefers an
entry, suggested wording: "Improved Buy widget reliability by
authenticating requests to the ramps API." -->
## **Related issues**
Fixes:
[TRAM-3502](https://consensyssoftware.atlassian.net/browse/TRAM-3502)
Depends on (core): `<link-to-core-PR>` — must be merged and released to
NPM before this PR can leave draft.
## **Manual testing steps**
```gherkin
Feature: Buy widget authentication
Scenario: Signed-in user opens the Buy widget
Given the user is signed in and the wallet is unlocked
And the user has selected a token that supports Transak
When the user taps "Buy" and proceeds to the Transak provider
Then the Buy widget URL loads successfully
And the upstream request to the ramps API includes an "Authorization: Bearer <token>" header
And Transak opens in the in-app browser as before
Scenario: Wallet-locked user attempts to open the Buy widget
Given the wallet is locked
When the user taps "Buy" and proceeds to the Transak provider
Then the user sees a clear error state (not a silent failure or crash)
And no unauthenticated request is sent to the ramps API
Scenario: Signed-out user attempts to open the Buy widget
Given the user is signed out of profile sync / authentication
When the user taps "Buy" and proceeds to the Transak provider
Then the user sees a clear error state
And no unauthenticated request is sent to the ramps API
Scenario: Bearer token call fails transiently
Given the AuthenticationController fails to mint a bearer token
When the user taps "Buy" and proceeds to the Transak provider
Then the failure is surfaced as a user-facing error
And retrying after the underlying auth issue is resolved succeeds
```
**How to verify the Authorization header on-device:**
- Point a debugging proxy (Charles / mitmproxy) at the device.
- Trigger the Buy flow and inspect the request to
`https://on-ramp.api.cx.metamask.io/providers/<provider>/buy-widget`.
- Confirm an `Authorization: Bearer <jwt>` header is present.
## **Screenshots/Recordings**
### **Before**
<!-- Recording of Buy widget on current `main`: request to /buy-widget
has no Authorization header. -->
### **After**
https://github.com/user-attachments/assets/b45d9a6e-3534-46f1-b51f-1d42637c32d0
<!-- Recording of Buy widget on this branch: same UX, request now
includes Authorization: Bearer <token>. Plus recordings of the
locked-wallet and signed-out error states. -->
## **Pre-merge author checklist**
- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
#### Performance checks (if applicable)
- [x] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.
[TRAM-3502]:
https://consensyssoftware.atlassian.net/browse/TRAM-3502?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
[TRAM-3502]:
https://consensyssoftware.atlassian.net/browse/TRAM-3502?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Wires bearer-token access into the Buy/ramps path; mis-delegation
would break Transak buy, but changes are localized to messenger setup
and a dependency bump.
>
> **Overview**
> Upgrades **`@metamask/ramps-controller`** to **^14.0.0** so the Buy
widget can call the ramps API with an authenticated bearer token
(required by the new controller contract).
>
> When **`getRampsServiceMessenger`** builds the child messenger, it now
**delegates** `AuthenticationController:getBearerToken` from the root
messenger into `RampsServiceMessenger`, so `RampsService` can mint
tokens without the call failing at runtime. A unit test asserts that
delegated call returns the token from the registered handler.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
c7e989f. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Darius Costolas <10818970+meltingice1337@users.noreply.github.com>
Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com>
Co-authored-by: Amitabh Aggarwal <aggarwal.amitabh@gmail.com>1 parent cae6c60 commit 044726b
4 files changed
Lines changed: 24 additions & 14 deletions
File tree
- app/core/Engine/messengers/ramps-service-messenger
Lines changed: 15 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
27 | 27 | | |
28 | 28 | | |
29 | 29 | | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
30 | 45 | | |
Lines changed: 7 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
19 | 19 | | |
20 | 20 | | |
21 | 21 | | |
22 | | - | |
| 22 | + | |
23 | 23 | | |
24 | 24 | | |
25 | 25 | | |
| |||
28 | 28 | | |
29 | 29 | | |
30 | 30 | | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
31 | 37 | | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
322 | 322 | | |
323 | 323 | | |
324 | 324 | | |
325 | | - | |
| 325 | + | |
326 | 326 | | |
327 | 327 | | |
328 | 328 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
9817 | 9817 | | |
9818 | 9818 | | |
9819 | 9819 | | |
9820 | | - | |
9821 | | - | |
9822 | | - | |
9823 | | - | |
9824 | | - | |
9825 | | - | |
9826 | | - | |
9827 | | - | |
9828 | | - | |
9829 | | - | |
9830 | | - | |
9831 | 9820 | | |
9832 | 9821 | | |
9833 | 9822 | | |
| |||
35551 | 35540 | | |
35552 | 35541 | | |
35553 | 35542 | | |
35554 | | - | |
| 35543 | + | |
35555 | 35544 | | |
35556 | 35545 | | |
35557 | 35546 | | |
| |||
0 commit comments