ci / node (pull_request) Skipped
ci / version (pull_request) Skipped
github/ci (branch) GitHub Actions
ci / github (pull_request) Successful in 2m24s
ci / docker-build (pull_request) Skipped
ci / publish (pull_request) Skipped
ci / announce (pull_request) Skipped
First of three for notifications with the app closed, for every signed-in account (multi-account spec, MA-8 part 2). No behavior changes yet. A JMAP push subscription belongs to whoever signs the request, so an account that isn't in front can only have one registered, verified and renewed through its own session. POST /api/auth/accounts/<sessionId>/jmap forwards to the mail server as that session, when it is one of this browser's other accounts, and only for PushSubscription/get and /set, Mailbox/get, and Email/set limited to keywords and mailboxIds updates (what a notification's Archive and Mark read need). Anything else is 403; the account in front, or a session this browser doesn't hold, is 404. Its OAuth token is renewed first if due. The browser already holds the session, so nothing new becomes reachable. On the web app side the push helpers (list, create, extend, destroy, verify) take a JMAP caller, defaulting to the account in front exactly as before, and lib/notify/otherAccount gives the caller for another account through the route. Tests: the allowlist, the route end to end with two accounts (allowed, refused, front and unknown sessions), and the caller. The accounts test file now raises LOGIN_RATE_LIMIT, since it signs in more often from one address than the default allows. typecheck, tests (web 1543, server 278) and build pass.