ScopeAuth Plugin with Prisma - Possible to Access Nested parent Fields?

[arimgibson]

Hi! Currently working to implement the scope auth plugin on a project that is also using the Prisma plugin. I've noticed that when using authScopes inside a type, the parent parameter only contains information about the fields directly exposed on this type, and does not respect t.relation fields that fetch nested data through Prisma.

I'm assuming there's no way currently to fetch those nested fields by passing in the Prisma query manually to the scope auth plugin. Please let me know if there is; otherwise, I believe this is the best way to fetch that data as of now:

builder.prismaObject('User', {
  runScopesOnType: true,
  authScopes: async (user, context) => {
    const nestedUser = await db.user.findUnique({
      select: {
        organization: {
          select: {
            id: true
          }
        }
      },
      where: {
        id: user.id
      }
    });
  },
})

This does require extra database calls, and is likely not as performant. When Pothos fetches the data for the parent parameter, does it also cache this data to return if the query asks for it?

Edit: answering my own question for that last part -- whether Pothos caches that data. I'm going to assume that wouldn't be possible because Pothos would still need to call the resolver function to return all data the user requested. For example, if the authScopes rely on user.organization.id but not user.organization.name and the user requests the name, it has to refetch anyway. Probably easiest if it refetches anyway without checking if the cached values are sufficient

[hayes]

The data should be there, but there is no way to make it type-safe in the authScopes handler. The nested data is dependent on what was queried. Only data that is always selected is available in the types for parent, but the data should still exist on the parent object.

If you want to always load data, you can use include or select on the type:

builder.prismaObject('User', {
  include: {
    organization: {
      select: {
        id: true
      }
    }
  },
  runScopesOnType: true,
  authScopes: async (user, context) => {
    console.log(user.organization.id)
  },
})

[hayes]

to answer your question about caching data:

Pothos analyzes the dependencies for all nested selections before resolving the root level query, so if you have a query like:

query {
  user(id: 1) {
    organization {
      name
    }
  }
}

With the above include for orgnanization.id

Pothos would know that it should select:

{
  include: {
    organization: {
      select: {
        id: true,
        name: true,
      }
    }
  }
}

This would be part of the query passed to the resolver for the user field. that query contains selections for all selected sub-fields, as well as includes/selects for on the object types as shown above.

[hayes]

In practice this would work slightly differently. By default Pothos includes full types, and you would need to define a select on the Organization type if you want to only select the relevant fields. By default it would actually select something like:

{
  include: {
    organization: true
  }
}

If you were to omit the organization from the query it would then select:

{
  include: {
    organization: {
      select: {
        id: true,
      }
    }
  }
}

Because the User type only depends on ornanization.id and uses a select for the id

[arimgibson]

Ah, that makes sense that the Pothos just needs to know which data should be fetched. I haven't tried this yet but would think that the first parameter of authScopes, user in this case, could be typed manually: authScopes: (user: User & { organization?: Pick<Organization, "id" | "name"> }

With the caching, does that mean that Pothos runs the database query for all the fields first, then determines based on auth scopes if the data should actually be returned?

[hayes]

no need for manual typing, if you use include/select Pothos will take care of the types for you.

With the caching, does that mean that Pothos runs the database query for all the fields first, then determines based on auth scopes if the data should actually be returned?
Yes.

Basically what prismaObject, t.expose, t.relation, t.relatedConnection, t.fied with a select, etc are doing is just annotating the schema with exactly what data is required to resolve those fields.

When you use t.prismaField it looks at the graphql query for what fields are requested, and then generates a prisma query (the first arg) that selects/includes as much of the required data as possible. Then the resolvers for all those fields are pretty boring resolvers lile (parent) => parent.posts that just return the data that was already loaded (there is some fallback logic in case things couldn't be loaded in the initial query, but we can ignore that for now). When you have an authorization check for a type or resolver that runs just as it would for any other field, which would generally be when that field is resolved (and after the data has been loaded).

If you want to avoid this, you would just avoid using t.prismaField (which is designed for this type of optimized loading). Many auth checks depend on having loaded the data already, so this isn't something that could be easily changed in pothos.