Skip to content

feat(hutch,ios): discover the reader session-mint action instead of hard-coding it#925

Merged
FagnerMartinsBrack merged 1 commit into
ios/testable-view-seamsfrom
ios/discover-session-action
Jul 5, 2026
Merged

feat(hutch,ios): discover the reader session-mint action instead of hard-coding it#925
FagnerMartinsBrack merged 1 commit into
ios/testable-view-seamsfrom
ios/discover-session-action

Conversation

@FagnerMartinsBrack

Copy link
Copy Markdown
Member

Stacked on #924 (base = ios/testable-view-seams). Review/merge after it. Server + client — deploy the server first (the action is additive; older clients keep working).

Purpose

The iOS in-app reader mints a browser session cookie from the bearer token before loading the cookie-authenticated reader page. The client hard-coded that route and method (POST /auth/session), so a server-side rename would break every article tap ("Couldn't open the reader") until an App Store release — the flagship URL-coupling the hypermedia contract exists to remove, sitting on the app's core flow in its slowest-shipping client.

What changed & the value

  • Server (collection-siren.ts): advertise a create-session action on the collection — href: /auth/session, method: POST. No fields (the route reads the bearer from the Authorization header) and no title, because it's a machine capability a client invokes bespoke, not a rendered control (mirroring the untitled save-articles). Additive and non-breaking: a client without a handler skips it.
  • Client: discover the action from the loaded collection and follow its href + method to mint the session — no route baked into the app. create-session maps to a non-toolbar presentation so it never renders as a control. A server that hasn't advertised it yet falls back to the fixed path, so an older shipped build keeps working (App-Store back-compat).

Now a server can move /auth/session by changing the action's href; the client follows it with no release.

Deploy ordering

Deploy the server (advertising create-session) before it matters; the client change is safe to ship in either order thanks to the fallback.

Testing

  • Server: collection-siren.test.ts green (18 tests incl. the new create-session assertion); pnpm check passes.
  • Client: full iOS suite green (251 tests) incl. a bootstrap test that follows a discovered action to /custom/session and a VM test that mints via the server-advertised action; coverage gate + STAGING smoke pass.

…ard-coding it

The iOS reader mints a browser session cookie from the bearer token before
loading the cookie-authenticated reader page. The client hard-coded that route
and method (`POST /auth/session`), so a server-side rename would break every
article tap until an App Store release — the exact URL coupling the hypermedia
contract exists to remove.

- Server: advertise a `create-session` action on the collection (href
  `/auth/session`, method POST). It carries no fields — the route reads the bearer
  from the Authorization header — and no title, since it is a machine capability a
  client invokes bespoke rather than a rendered control (like `save-articles`).
- Client: discover the action from the loaded collection and follow its href and
  method to mint the session; map `create-session` to a non-toolbar presentation
  so it never renders as a control. A server that hasn't advertised the action yet
  falls back to the fixed path, so an older shipped build keeps working.

The action is additive and non-breaking: a client without a handler skips it.
@FagnerMartinsBrack FagnerMartinsBrack merged commit 4fd41be into ios/testable-view-seams Jul 5, 2026
@FagnerMartinsBrack FagnerMartinsBrack deleted the ios/discover-session-action branch July 5, 2026 12:58
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