Skip to content

fix: read available roles from /obp/v7.0.0/roles instead of v2.1.0 - #7

Closed
hongwei1 wants to merge 1 commit into
OpenBankProject:mainfrom
hongwei1:fix/roles-endpoint-v7
Closed

hongwei1 wants to merge 1 commit into
OpenBankProject:mainfrom
hongwei1:fix/roles-endpoint-v7

Conversation

@hongwei1

Copy link
Copy Markdown
Contributor

Summary

  • The Opey consent handler and the portal roles route call GET /obp/v2.1.0/roles to list available roles.
  • Deployments that only enable newer API versions (for example OBP_API_ENABLED_VERSIONS=[OBPv4.0.0 ... OBPv7.0.0,dynamic-entity]) return OBP-10404: 404 Not Found for that URL, and the consent card shows the error.
  • /roles is defined in v2.1.0 but newer versions inherit it, so /obp/v7.0.0/roles serves the same endpoint (same roles[].role and requires_bank_id fields). On such a deployment /obp/v7.0.0/roles answers 401 without a token (route exists) while /obp/v2.1.0/roles answers 404.

Changes

  • packages/shared/src/lib/server/opey/consentHandler.ts: /obp/v2.1.0/roles -> /obp/v7.0.0/roles
  • apps/portal/src/routes/backend/obp/roles/+server.ts: /obp/v2.1.0/roles -> /obp/v7.0.0/roles

Test plan

  • On an instance without API v2.1.0 enabled, open the Opey consent card and confirm the OBP-10404 error no longer appears
  • Confirm the bank-scoped / system-scoped role selection in the consent still works

@hongwei1

Copy link
Copy Markdown
Contributor Author

Closing: the roles endpoint stays on v2.1.0.

@hongwei1 hongwei1 closed this Oct 29, 2026
simonredfern pushed a commit that referenced this pull request Oct 30, 2026
Each was found by resolving every call site in this repository against OBP-API's
published resource-docs, and each was confirmed against a live develop-obp
(3df73fe11) with the verb held constant, so none of them is the
404-for-a-wrong-verb ambiguity.

Portal, accepting a user invitation (#5)
  obp_requests.put -> post. /obp/v4.0.0/banks/{id}/user-invitation is POST-only at
  v4.0.0 and v6.0.0 alike; PUT answers 404 OBP-10404 while POST answers 401. The
  same file already POSTs the sibling /user-invitations path correctly, and
  API-Manager POSTs this one correctly, so the convention was established in two
  other places and only this call site diverged.

  Fixing the verb alone did not make the flow work, which the new test caught: the
  redirect was thrown inside the try, and the catch-all below it turns anything
  that is not an OBPRequestError into "Failed to create account: Unknown error".
  redirect() signals by throwing, so a successful account creation reported
  failure. The redirect now returns after the try/catch, matching what the
  register action already does.

Portal, removing a chat reaction (#6)
  The emoji moves from the DELETE body into the path: OBP-API serves
  .../reactions/{emoji} for DELETE and only POST/GET on .../reactions. The
  response is now checked with res.ok, mirroring the add branch immediately below
  it. fetch does not reject on 4xx, so the old try/catch could not see the failure
  -- the reaction vanished from the UI, stayed in the database, and returned on
  reload with nothing logged. The add path was already correct and is untouched.

API-Manager, creating a custom view (#7)
  routes/backend/obp/banks/[bank_id]/views/+server.ts is deleted rather than
  repaired. It targets /obp/v6.0.0/banks/{id}/views, which OBP-API does not serve
  at any verb -- every view endpoint is account-scoped -- and nothing calls it: the
  custom-view page posts to the account-scoped route next to it, which builds the
  correct URL. It was a copy of a working route with the account segment dropped.

Adds apps/portal/src/routes/user-invitation/page.server.test.ts, following the
pattern of the register action's test. It asserts the verb rather than only the
URL, which is what lets it fail if this regresses, and it is what surfaced the
swallowed redirect.

Verified: portal 86/86 unit tests pass, api-manager 15/15. svelte-check is
unchanged against the base commit on both apps (portal 21 errors/70 warnings,
api-manager 22/332), so no new type errors. Both apps build.
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