feat(security): let a consumer supply the access token via setAccessTokenResolver

[gcutrini]

ref: https://app.clickup.com/t/86bbnquuq

5.x line companion of #324 (same change on the v4.x line).

uicore's getAccessToken assumes the access token lives on the client. It reads and refreshes the token from local storage and serializes refreshes with navigator.locks. That model does not fit a server-rendered host such as the Next.js event site, where the token is held in an encrypted httpOnly cookie and is never exposed to JavaScript. There is no client-side token for uicore to read, lock, or renew.

Keeping the token out of JavaScript is also a deliberate security property. A token that never reaches the browser's JS context cannot be stolen by XSS or replayed from client code.

Several uicore modules call getAccessToken, so the source must be injectable inside uicore rather than overridden by the consumer. Today a cookie-based host has to work around this by aliasing security/methods at build time and substituting its own implementation, which is invasive (build-system specific, replaces the whole module) and easy to drift out of sync.

What

Add setAccessTokenResolver to security/methods: a consumer registers where the access token comes from, without replacing anything.

• It does not bypass getAccessToken. When a resolver is registered, getAccessToken delegates to it; otherwise the built-in flow is unchanged. Passing a non-function resets to the built-in.
• It is opt-in. Existing consumers such as summit-admin are unaffected; there is no behavior change unless they call setAccessTokenResolver.

Renewal is the consumer's concern

When a resolver is registered, uicore delegates token retrieval to it and does not apply its own storage, locking, or renewal to the returned value. Freshness is left entirely to the consumer. A cookie-based host, for example, renews server-side (the server refreshes the session cookie via the refresh_token grant, and proxied API calls attach the real bearer from the cookie) and hands uicore only a "session present" placeholder, so there is nothing on the client to lock or renew.

Implementation note

The resolver is module-level state, so security/methods is also externalized in the webpack build. That way every uicore lib entry shares one methods instance and sees the registered resolver; otherwise an entry that inlines its own copy keeps its own null resolver and ignores it.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 55630ecc-229a-4b25-a323-fbe67c38d516

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}