Auth Scopes & relayMutationField -- Providing parent to Scope?

[arimgibson]

I've got an auth setup that allows admin users to read certain data of user's who belong the organization that admin manages. This is super easy to configure using the parent value in the prismaNode where the user's object type is defined. parent is the first parameter passed into the auth scopes, which is user in this case:

  authScopes: (user) => ({
    developer: true,
    admin: user.organization_id,
    teacher: user.id,
  }),

However, when trying to add auth onto a relayMutationField, the parent object is always empty. This empty object is both shown through TypeScript and upon logging the parent value. Is there a way to add the user's data into the mutation, or another way to configure this? My thought would be to have the resolver fetch the user from the database and then perform custom auth logic inside the resolver, independent from Pothos.

builder.relayMutationField(
  'deleteUser',
  {
    inputFields: (t) => ({
      id: t.globalID({
        required: true,
      }),
    }),
  },
  {
    authScopes: (user, args) => ({
      developer: true,
      teacher: parseInt(args.input.id.id, 10),
      // admin??
    }),
    resolve: async (root, args) => deleteUser(root, args),
  },
  {
    outputFields: (t) => getOutputField(t, UserNode),
  },
);

It's worth noting that the parent value does contain data in the payloadOptions field (3rd param, contains the outputFields in the above example) but at this point, the mutation has already been performed. From my understanding, this field just determines whether the client can view the data returned by the mutation

[hayes]

The parent of a mutation field is the "root" object (empty in most APIs, not the value returned from the resolve function. Pothos doesn't know anything about your User type, and the check would need to run before you try to delete the user (before you run the resolver).

What you can do istead is move the auth checks into your resolver.

{
  resolve: async (root, args, ctx) => {
    const user = await loadUser(args)
    await builder.runAuthScopes({
      developer: true,
      teacher: parseInt(ctx, args.input.id.id, 10),
      admin: user.organizarion_id
    })
   return deleteUser(args)
  }
}

[arimgibson]

Ah, that's perfect, thanks! Didn't realize there was a way to a way to invoke authScopes outside of the key on some of the object. Realizing too that the only reason that the payloadOptions has access to user data in my case is because our mutations return the user object. Makes sense that isn't universal and Pothos otherwise wouldn't have access to the user data.

builder.runAuthScopes required a first parameter with the context for me; not sure if that's a quirk of my setup or slipped by you when writing that example 😃

[hayes]

Yes, context is required, wrote that comment from my phone, so it was just an oversight. Auth checks are cached via the context object, so it's required

[hayes]

Yes, context is required, wrote that comment from my phone, so it was just an oversight. Auth checks are cached via the context object, so it's required