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

[gcutrini]

uicore fetches the access token internally, and a consumer has no way to supply one. Several uicore modules call getAccessToken, so the source must be injectable inside uicore rather than overridden by the consumer.

Add setAccessTokenResolver to security/methods: 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.

The resolver is module-level state, so also externalize security/methods 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

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}

[smarcet]

@gcutrini i cant approve this , this bypass entirely the renewal flow please provide a rationale for this

[smarcet]

@gcutrini following up on the earlier request for a rationale: the current PR description explains why the resolver has to live inside security/methods (multiple internal call sites: security/actions.js, utils/query-actions.js, attendance-tracker.js, inputs/dropzone/index.js) and why webpack.common.js needs the externals change (multi-entry UMD build, module-level state duplicated per bundle otherwise) — both check out against the code.

What's still missing is the actual concern raised: when _resolveAccessToken is set, getAccessToken() returns _resolveAccessToken() directly (methods.js:349), bypassing the cross-tab mutex (navigator.locks/SuperTokensLock), the expiry check against ACCESS_TOKEN_SKEW_TIME, and the automatic refresh + storeAuthInfo persistence in _getAccessToken. Two things need an answer before this can be approved:

1. What's the concrete use case that requires bypassing the entire pipeline, rather than a narrower hook that only swaps the token source while _getAccessToken still owns expiry/refresh?
2. Once a resolver is active, who is responsible for renewal — is the consumer's resolver expected to reimplement expiry checking and refresh itself? If so, that contract should be documented (JSDoc on setAccessTokenResolver), since every module that currently benefits from automatic renewal (query-actions, attendance-tracker, dropzone, security/actions) will silently stop renewing once any part of the app calls setAccessTokenResolver.