Plugin route context should expose authenticated user (routeCtx.user)

[robby3000]

I've been exploring the idea of building an EmDash plugin that communicates with a separate PWA. The idea being that users can collect content in the PWA and then easily bring it into EmDash posts from within the admin panel. I'm not a highly proficient coder, but I'm learning fast and trying to understand what's actually possible at the architecture level before I build.

To figure out how auth would work across the plugin and the external PWA, I did a systematic probe of the plugin route system - with some AI assistance helping me read the source where my own skills run thin. I wanted to share what I found, because I think it touches on some architectural questions that might be relevant beyond my own use case.

What I investigated
The core question: when a plugin route handler receives a request that carries a valid EmDash admin session cookie, does routeCtx expose the authenticated user?

What the probe found
Short answer: no. Source analysis traced the full path - the middleware in handlePluginRouteAuth correctly resolves locals.user from the session cookie and does a DB lookup. But at the Astro --> plugin boundary (in the [...path].ts route handler), user is only used for permission-gating private routes. It isn't passed into handlePluginApiRoute, so it never reaches the plugin handler. routeCtx only ever contains { input, request, requestMeta }.

Two other things we discovered along the way that feel worth flagging:

1. Plugin routes can't return raw Response objects or perform HTTP redirects - return values are always wrapped as { data: ... }. This shapes what's possible in auth flows quite significantly, since you can't bounce users around with redirects from within a plugin handler.

2. EmDash middleware intercepts Authorization: Bearer headers before the plugin handler runs, and rejects anything that isn't a valid EmDash token. So plugin-issued tokens have to travel via a different header (we used X-Auth-Token as a workaround).

What this means architecturally
For anyone building a plugin that needs to know who is making a request - not just whether they're an authenticated admin - the current design creates a gap. The session is validated by middleware, but that validated identity doesn't flow through to the plugin. The workaround we landed on (using ctx.users.list() to infer the user on single-admin sites, and making /connect a private route so middleware enforces auth) is functional, but it's a workaround rather than a clean solution.

A one-line fix that was identified
In src/astro/routes/api/plugins/[pluginId]/[...path].ts, line 68, the proposed change is:

- const result = await emdash.handlePluginApiRoute(pluginId, method, `/${path}`, request);
+ const result = await emdash.handlePluginApiRoute(pluginId, method, `/${path}`, request, user);

…and then threading user through handlePluginApiRoute --> routeRegistry.invoke --> routeContext so that routeCtx.user is available to plugin handlers when a valid session is present.

I don't fully understand all the downstream implications of this - there may be sandbox isolation reasons or other considerations that make it more complex than it looks. But from the outside it appears to be a meaningful capability improvement for plugin authors.

My questions for the team / community:

• Is the current behaviour (user not flowing into plugin context) intentional - a sandbox isolation decision - or is it an oversight?
• Is this something that's likely to change as the plugin API matures, or is it a fixed design constraint?
• Does the one-line fix above look viable to those who know the codebase well, or does it open up problems I'm not seeing?

Happy to share more of the probe results if that's useful. And if I've misread anything (very possible given where I am on the learning curve!) please do correct me.

[vikramrojo]

I'm stuck on a similar issue where every authenticated user needs their own plugin configuration.