Feature: support reading request "context" in server actions

[jwbay]

My goal here is to support session-based authentication for server actions in RSC.

Authentication for server actions seems like an open question at this point, but step one is making some kind "current context" from the caller available to the action. For a client holding access tokens, it's probably trivial to wire up helpers to invoke actions with. However, for battle tested session cookie-based authentication, there seems to be some work to do.

The same problem could surface for any other data sourced from the server request that needs to be supplied to actions.

As far as prior art, the next.js examples imply a backend like AsyncLocalStorage, given this code:

import { cookies } from 'next/headers';
 
export default function AddToCart({ productId }) {
  async function addItem(data) {
    'use server';
 
    const cartId = cookies().get('cartId')?.value;
    await saveToDb({ cartId, data });
  }
 
  return (
    <form action={addItem}>
      <button type="submit">Add to Cart</button>
    </form>
  );
}

To start, I briefly explored adding support for reading request headers in server actions. Two things got in the way:

1. The action handlers are run in a worker, separately from the express handler. This means even on the server, anything originating from the request cannot share module state with an action, and instead must cross a thread boundary via postMessage. This stopped a simple AsyncLocalStorage approach from working. I'm curious if RSC prescribes the worker in some way
2. The server code is bundled and loaded by Vite. This is what stopped me (for now) from simply importing a module from the server code and seeding AsyncLocalStorage with something around this spot: https://github.com/dai-shi/waku/blob/0848fa64eac2a578f602d7ab460889a8124bbbb0/src/lib/rsc-handler-worker.ts#L228C1-L229 The bundled action code gets its own module graph, and I couldn't easily figure out how to access a known module in that graph from the worker source to seed it with a value.

That fiddling can be found here, if interested: https://github.com/dai-shi/waku/compare/main...jwbay:request-headers?expand=1

The interesting output is:

✓ built in 1.15s
clientEntries { 'assets/rsc0.js': 'assets/rsc0-1b0f0351.js' }
Creating header store @     at eval (/home/admin/source/waku/examples/05_mutation/dist/assets/headers-storage-b5646013.js:5:40)
3:44:00 PM [vite] page reload dist/public/index.html
Listening on 8080
Creating header store @     at file:///home/admin/source/waku/dist/lib/headers-storage.js:2:40
Creating header store @     at eval (/home/admin/source/waku/examples/05_mutation/dist/assets/headers-storage-b5646013.js:5:40)
user-agent in worker src:  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0
user-agent in action:  undefined

Possibly the simplest alternative is to .call/.apply the server action with a this value containing request context. Making it a first/last parameter is also possible, but would require some TS trickery.

[dai-shi]

Thanks for the write-up. Yeah, the server integration is an open problem. The first is API design. It should work for server components, not only server actions. The second is the worker boundary as you said. Is IncomingHttpHeaders serializable? That looks good.

I can try the AsyncLocalStorage approach too.

[dai-shi]

The bundled action code gets its own module graph, and I couldn't easily figure out how to access a known module in that graph from the worker source to seed it with a value.

Can you try this in src/lib/rsc-handler-worker.ts?

  const { withHeadersStore } = await loadServerFile('waku/server');

You also need to export it from src/server.ts.

[jwbay]

const { withHeadersStore } = await loadServerFile('waku/server');

This did the trick! I can now get to the request headers from the action. I updated the branch. And yes, the headers are serializable.

(I would note that I'm not necessarily proposing the current getRequestHeaders API as-is, the goal for the branch was to prove out wiring.)

I'd consider it a successful experiment, for now. Getting it working for server components might not be that difficult. I can see how that's important for consistency.

[dai-shi]

That's great to hear.

So, the remaining issue is API design. Waku wants to be as thin as possible (and extensible).
What else do people want to read from req other than headers?
And do we need to write to res, right??

[jwbay]

I don't have much experience with RPC-style comms, so it's possible slapping stuff from the http request in there is not a good idea, at large. However, it might be worth enumerating what we have with this so far:

• method - N/A, I'd say everything's a POST
• url/path - this is functionally (and possibly literally) the server function name
• headers - covered in this issue
• body/params - server function arguments

Next, there are two angles at play here: Header access and authentication. These could probably be split into two issues.

I'll say session authentication is related and probably needs header access, but beyond that, I'm unsure of how it should be handled in RSC. RPC libraries and specs in general will have prior art to explore here. For example, gRPC supports both a "channel credential" for an entire connection, and a "call credential" for a specific call. Since RSC's caller is a web client, per-call creds are unlikely, imo, and yet if someone is doing token management on the client, it's possible. The next step is probably just a bunch of poking around to see what's been done before.

As far as headers, there are some reasons for and against even exposing them to actions. (If they're not exposed, I would expect the framework would at least provide something for reading cookies, as nextjs does.) On the for side:

1. The framework is unopinionated and flexible
2. Provides familiarity to web developers

On the against side:

1. These are not normal HTTP requests, it's an RSC RPC over HTTP. Exposing headers breaks that containment
2. Since headers can't be set during server action calls, it's possible raw headers may not even be that useful. Exposing smaller slices of what people want from headers that they can't get from the client browser (to be passed as arguments) may be the better play

[dai-shi]

@jwbay See #86 for my take (still work in progress).