fix(clerk): Remove privateMetadata property from getCurrentUser

[anagstef]

The privateMetadata property should not be accessible on the client side. This commit removes this property from the getCurrentUser function returned user object.

[replay-io]

16 replays were recorded for d18ab63.

0 Failed

16 Passed

requireAuth graphql checks

locator.waitFor: Target closed
=========================== logs ===========================
waiting for locator('.rw-form-error-title').locator('text=You don\'t have permission to do that') to be visible
============================================================

• useAuth hook, auth redirects checks
• Check that tags are rendering the correct dynamic data
• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• 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 ↗︎

[BurnedChris]

This won't fix the actual problem. Just stop the API using PrivateMetadata.

I propose overwriting the default redwood currentUser with the ability to remove parts that you may want to be available in the backend context but not pass back to the front end, such as privateMetadata

redwood/packages/graphql-server/src/rootSchema.ts

Line 79 in f044dcd

currentUser: (_args: any, context: GlobalContext) => {

[BurnedChris]

Clerk need to override the default currentUser function to remove privateMetadata, It cant be done in the auth.ts, as the privateMetadata is needed in the the context for other resolvers.

Example on how to remove privateMetadata being sent to the frontend useAuth Hooks

export const resolvers: Resolvers = {
  BigInt: BigIntResolver,
  Date: DateResolver,
  Time: TimeResolver,
  DateTime: DateTimeResolver,
  JSON: JSONResolver,
  JSONObject: JSONObjectResolver,
  Query: {
    redwood: () => ({
      version: redwoodVersion,
      prismaVersion: prismaVersion,
      currentUser: (_args: any, context: GlobalContext) => {
      const { ...userWithoutPrivateMetadata, privateMetadata } = context?.currentUser
        return userWithoutPrivateMetadata
      },
    }),
  },
}

[dthyresson]

It seems to be that the currentUser in global context — and the same info passed back to client — should be “safe” data to share.

If private data is needed elsewhere in the api side (or web side) then I’d argue that should be an explicit request to ensure that it’s ok to show this info for the given user.

I could see this being done:

a) via a Clerk backed api call
b) via a Yoga plugin like useRedwoodAuthContext that populates context.fullCurrentUser that is given a function that sets it with the full decoded value
c) Instead of a second plugin, useRedwoodAuthContext takes an optional function that populates that additional global context “complete or full currentUser”

[dthyresson]

Another approach would be to do the “sanitizing” at the decoder level here:

redwood/packages/auth-providers/clerk/api/src/decoder.ts

Line 26 in f044dcd

const user = await users.getUser(jwtPayload.sub)

if there is a Clerk api method that gets only a subset of “safe” user attributes and use that … or deconstruct there instead of in the getCurrentUser

[Tobbe]

After discussing this in the team we decided that this is the quickest solution that's the best option for most people.
Unfortunately it breaks @BurnedChris's use case. For advanced uses like his, you'd have to (for now) go back to the way it was before this PR
We'll continue working on a better solution, but wanted to get this fix out as soon as possible