Changing the default access control on the REST API? (multiple auth-enabled collections)

[LucienLeMagicien]

Hello, I just started trying Payload out (it's been pretty great so far!), so sorry if I missed something.

The Admin Overview page says that it's possible to have multiple collections that support Authentication (for example admins and customers) so I went with this pattern. This same page says that setting admin: { user: 'admins' } in my Payload Config makes sure the Admin panel uses the admins collection.

However, when I use the REST API to log in through the customers collection, then GET /api/access, it tells me I have full create/read/update/delete rights to every collection, including admins and internal ones like payload-locked-documents, payload-preferences and payload-migrations.

I'm not sure if this is somehow wrong (I assume that the payload-preferences collection checks that the user id matches), but it makes sense: the Access Control page says that the "Default access control" looks something like this:

const defaultPayloadAccess = ({ req: { user } }) => {
  // Return `true` if a user is found
  // and `false` if it is undefined or null
  return Boolean(user) 
}

Which would also return true to my customers users.

To limit access to admins users, I have written a simple Access check:

import { Admins } from "@/collections/Admins.ts";
import { FieldAccess } from "payload";

export const mustBeAdmin: FieldAccess = ({ req: { user }}) => user?.collection ===  Admins.slug;

However, I can't seem to find a way to override the defaultPayloadAccess function. Do I need to go through all my collections and set access? (Is this something I should be doing anyway?)
If so, how do I set access on internal collections (payload-locked-documents, payload-preferences and payload-migrations)?Or am I missing something obvious?

Thanks!

---

For the record, it seems that the "auth" RBAC example would have the same issue. It only has a Users collection, but I don't see how it would avoid having to set access for every collection manually:

payload/examples/auth/src/collections/Users.ts

Lines 23 to 29 in ef527fe

	access: {
	read: adminsAndUser,
	create: anyone,
	update: adminsAndUser,
	delete: admins,
	admin: ({ req: { user } }) => checkRole(['admin'], user),
	},

(This example also seems to disable access to the Admin Panel to users without the "admin" role, but as far as I can see they'd still have access to the API and full permissions to the internal tables.)

---

Edit after looking through the code:
The payload-locked-documents collection was recently made auth-only: #11624, though as far as I can tell it's still accessible for non-"admin" users

The payload-preferences collection (as I suspected) makes sure all calls to it are from it's owning user. However from what I can tell, the preferenceAccess check doesn't make sure that the current user is from the right collection, so an user in my customers table with id 1 could read preferences of the user with id 1 in the admins collection.

payload/packages/payload/src/preferences/config.ts

Lines 9 to 19 in ef527fe

	const preferenceAccess: Access = ({ req }) => {
	if (!req.user) {
	return false
	}
	return {
	'user.value': {
	equals: req?.user?.id,
	},
	}
	}

However, it does check correctly in updateHandler

payload/packages/payload/src/preferences/operations/update.ts

Lines 20 to 26 in ef527fe

	const where: Where = {
	and: [
	{ key: { equals: key } },
	{ 'user.value': { equals: user.id } },
	{ 'user.relationTo': { equals: user.collection } },
	],
	}

(But I don't think this handles changes made through the graphQL API?)
(By the way, the documentation on custom endpoints doesn't specifically mention that you can override the handlers this way:

payload/packages/payload/src/preferences/config.ts

Lines 43 to 47 in ef527fe

	{
	handler: updateHandler,
	method: 'post',
	path: '/:key',
	},

)

And finally The payload-migrations collection has it's REST and GraphQL API disabled, so there's no problem for this one:

payload/packages/payload/src/database/migrations/migrationsCollection.ts

Line 8 in ef527fe

endpoints: false,

[yunus-emre-zengin]

I am having the same issues, probably going to use pnpm patch 😔