Recommended way to disable query access on one list but allow read access on relationship field in another list

[caronbletzer]

I have some access functions as follows:

const isLoggedIn = ({ session }: { session: Session }) => !!session?.data
const isAdmin = ({ session }: { session: Session }) => Boolean(session?.data.isAdmin)

A user list:

const User = list({
  access: {
    operation: {
      query: isAdmin,
      create: isAdmin,
      update: isAdmin,      
      delete: isAdmin,
    }
  },
  fields: {
    name: text(),
    isAdmin: checkbox(),
  },
});

And a task list:

const Task = list({
  access: isLoggedIn,
  fields: {
    name: text(),
    assignedTo: relationship({ 
       ref: 'User',
       access: { read: isLoggedIn }
    }),
  },
})

I only want admin users to be able to query the users list, and logged in users to be able to query task.assignedTo e.g.

query {
  task {
    name
    assignedTo {
      name
    }
  }
}

assignedTo field is not populating because of the access.query restriction on user list.

I know I can create a virtual field for the task.assignedTo and use context.sudo().db.Task, but I have many lists with a similar relationship to a user and it seems like Keystone should provide a way to configure this.

I think my expectation would be that the read access on the relationship field should override the list access on the related list. e.g Task.assignedTo field access policy should override User list access policy.

[marekryb]

Hi,

I think my expectation would be that the read access on the relationship field should override the list access on the related list. e.g Task.assignedTo field access policy should override User list access policy.

If you allow access to a resource from inside some query then this is no different (from hostile actor point of view) from giving access explicitly. Unless you are exclusively using persisted queries or limiting other way (virtual field, custom query), anyone can execute a query that takes additional data (except from name) using assignedTo relation.

Depending on your exact requirement there several ways you could make it happen instead:

1. Change User list query permission to isLoggedIn and protect individual fields that need protection (email, phone number etc)
2. Split User to Account (private data - only admin) and User (public data - anyone logged in)
3. You could utilize list access filters for runtime checks. If only currently logged in user can view his/her's info, then you could write something like:

access: {
  operation: {
     query: () => true
     create: isAdmin,
      update: isAdmin,      
      delete: isAdmin,
  }
  filter: {
    query: ({ session }) => {
      if (!session) {
        return false;
      }
      if (session?.data.isAdmin) {
        return true;
      }
      return { id: { equals: session.id } };
    },
  }
}

You could probably make a two-way relationship between User and Task and write more complex filter that would take account of Task.assignedTo when checking User permission. It could work, but since you have multiple tables like this, performance would be probably very bad.

4. You could store user name in noSQL-style (without relation), which makes some sense for something like comments, reivews etc.

Anyway solution 1 or 2 is what I would recommend.