Skip to content

Conversation

geelen
Copy link
Contributor

@geelen geelen commented Jun 4, 2025

This lets a user add additional context per-request to their ApiHandler, by providing a customProps callback. The resulting object will be added to ctx.props.customProps:

new OAuthProvider({
  // ... other options ...
  customProps: async (request, env, ctx) => {
    // Will be added to ctx.props.customProps when invoking apiHandler
    return {
      customToken: request.headers.get('x-custom-token'),
      featureFlags: await env.FEATURES.parse(request.headers.get('x-feature-flags')),
    }
  }
})

This fixes #36

@geelen geelen requested a review from kentonv June 4, 2025 02:30
@kentonv
Copy link
Member

kentonv commented Jun 4, 2025

Why is this needed? The ApiHandler receives the original request, so why can't it just read the headers directly?

@geelen
Copy link
Contributor Author

geelen commented Jun 4, 2025

Ah this is probably another case of the Agents + Oauth combo hiding where the fix needs to happen. Agents does this: https://github.com/cloudflare/agents/blob/main/packages/agents/src/mcp/index.ts#L608

await doStub._init(ctx.props);

So anything you add to ctx.props would have come right through. But yeah, potentially it's the McpAgent api that needs an API extension to allow converting headers to props instead, if it's already getting the raw request?

@kentonv
Copy link
Member

kentonv commented Jun 4, 2025

Yes, that seems right to me -- this should be pushed up to the agents layer.

Though my opinion: I would find a way to separate this from ctx.props entirely. Maybe add a new parameter for "request info". ctx.props is meant to be info about the connection / grant / capability that the client exercised, not information about the request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FR: maintain ctx.props
2 participants