Distinguishing Dashboard Panel and External API Requests

[simonecorsi]

Hello everyone 👋

I would like to propose a simple DX enhancement that would greatly improve access control and hooks capabilities.

Currently, I don't see any way to distinguish, in an easy and straightforward way, if a request is coming from a public request or from the Dashboard, we assume it using the origin headers, which are notoriously unreliable (eg: proxies in front not forwarding). There is the req.payloadAPI but always returns REST from dashbaord or public API calls. I've searched the codebase for something like this but didn't find it.

Upon investigation, I noticed that list views append an invoke UUID to the query string, which could be leveraged to derive the necessary information. Unfortunately, this UUID is not appended to other REST requests.

To address this limitation, I suggest making improvements to the src/admin/api.ts file. We could include this information a cookie/header/queryString/whatever. We could then utilize this additional parameter in a middleware function to set a flag, such as isDashboardRequest (or any other appropriate name). This flag could be made available throughout the hooks and access mechanisms, enabling advanced filtering capabilities.

I would love to hear your thoughts on this proposed enhancement.

[ssyberg]

I came here to make this very request! Great idea, for now I'll be using invoke (also noticed that, but seems brittle!) since list view is the major bottleneck for disabling some behaviors, but agreed this would be awesome.

[ssyberg]

@simonecorsi though now I'm wondering if req.user could also somehow be harnessed?

[ssyberg]

Bumping this, we're still getting the occasional infinite loop that brings down admin. This seems like a really simple (yet important) fix, any chance we can add this to the roadmap?

[revnelson]

This would be great!

For example, I have a collection of Stores with a relationship field for a banner image. If a specific banner isn't set, a default image (set in a global) is returned in an afterRead hook:

import type { AfterReadHook } from "payload/dist/collections/config/types"
import type { Default, Store } from "@/types/generated"

const getDefaultsHook: AfterReadHook<Store> = async ({
	doc,
	req: { payload }
}) => {
	let defaults: Default

	const getDefaults = async () => {
		if (defaults) return defaults

		defaults = await payload.findGlobal({ slug: "defaults", depth: 2 })
		return defaults
	}

	// Get default banner if not set
	if (!doc.banner) {
		let banner = (await getDefaults()).banner

		// fetch banner if it's a reference
		if (typeof banner === "string") {
			console.log("Don't have banner, fetching from global")

			banner = await payload.findByID({
				collection: "images",
				id: banner
			})
		}

		doc.banner = banner
	}

	return doc
}

export default getDefaultsHook

This works well, but if I'm editing the Store from the dashboard, the default is loaded. This presents two problems:

1. I'd prefer the field to remain empty in the dashboard so any editors can clearly see the Store they're editing has no specific banner set.
2. When saving the item, the default banner gets saved with it. I'd like the ability to change the default banner from the global and have it reflected in all Stores that don't have an explicitly-set banner, but it's impossible to distinguish once the default has been saved into the collection item.

Preventing the afterRead hook from running if the request is coming from the dashboard would fix both issues for me.

[lorenzowijtman]

Specifically for this case, I've found that when your hook is called from the admin dashboard, the req.user variable will be set, and otherwise it will be empty. Although i'm not sure if this is still the case when you need your users to be authenticated from your (assumed) separate client application.

I have a method that is at the very start of almost all my hooks, the hook will not run if it returns false.
export const IsClientRequest = (req) => req.user == null && req.method != null

However, i am experiencing a problem where my hooks are called a lot (like 3 or 4 times instead of once). For that i also check if the findManyargument is undefined. Still figuring out that part but maybe the check on the user helps you.

[ssyberg]

I think invoke is no longer supported, but I wonder if there's something else we can inspect in middleware (the original request path?) and set something else on the request as a temporary workaround.