feat(clerk auth): make getToken options globally configurable

[jtoar]

Clerk users need to be able to configure how the auth provider calls getToken so that it always uses certain options. As far as I could tell this isn't possible right now. This PR suggests two different ways of doing it. Maybe we'll go with just one, or both, or neither, but it's important to at least get an RC out so that users can also tell us which solution they like.

The idea in this PR is that users could either provide a wrapper for getToken, or pass default options:

// web/src/auth.tsx

// ...

import { createAuth } from '@redwoodjs/auth-clerk-web'

export const { AuthProvider: ClerkRwAuthProvider, useAuth } = createAuth({
  // The user can provide a wrapper function (has to return a function)
  getToken: (cb) => (options) => cb({ ...options, option: value }),
  // Or they can provide an options object
  defaultGetTokenOptions: {
    option: value
  }
})

// ...

[replay-io]

15 replays were recorded for 2d14e22.

0 Failed

15 Passed

• useAuth hook, auth redirects checks
• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• Check that meta-tags are rendering the correct dynamic data
• Check that you can navigate from home page to specific blog post
• Waterfall prerendering (nested cells)
• RBAC: Admin user should be able to delete contacts
• RBAC: Should not be able to delete contact as non-admin user
• Smoke test with dev server
• Smoke test with rw serve
• Loads Cell mocks when Cell is nested in another story
• Loads Cell Stories
• Loads MDX Stories
• Mocks current user, and updates UI while dev server is running

View test run on Replay ↗︎

[Tobbe]

Great work on this @jtoar!

A third option here would be to have the users give the full getToken implementation, to make it closer to how useCurrentUser and useHasRole works.

Whatever we choose, I think we should only choose one.

If we go with what's currently called getToken, I think we should rename it getTokenWrapper, because that's more descriptive of what it actually does. And use internalGetToken instead of just cb in docs/comments when showing example usage.

Actually, having written all the above, maybe we should just name it getToken, and not frame it as a wrapper, but frame it as an option to provide a totally custom implementation. But also pass in the default internal getToken implementation so that people can use that in their own custom implementation if they want, so we give them the option to treat it as just a wrapper if they want to. And maybe we should think about doing the same for useCurrentUser and useHasRole too.

But the easier option, both for us and for our users right now is of course to make it possible to pass in default options. So maybe we should go with that for now, and switch over to the other, more powerful, alternative when someone actually needs it.

[jtoar]

Thanks @Tobbe, and sounds good, I've reduced the PR to just the defaultGetTokenOptions to keep things simple for now like you suggested