[RFC] Allow sending response headers from an origin response

[jensneuse]

Situation

• the WunderGraph user doesn't use WunderGraph Authentication
• the origin uses Cookie-based Authentication
• a mutation is used to authenticate a user
• the origin returns a Set-Cookie header
• there's no way to return the Set-Cookie header to the user

Problem

Currently, it's possible to do all kinds of things to "inject" data into origin requests.
However, we're quite un-flexible when it comes to returning data from a single origin request back to the client.
If data is part of the response body, it's ok, but headers are a problem.

So, ideally, we could add a hook for one specific operation and "forward" an origin response header to the client response.

However, this leads to another problem. We're only able to set a single origin hook.
If we configure an origin hook, it's applied to all operations.
That's a massive overhead because it means another round-trip and function call,
unnecessary most of the time.

To sum up the acceptance criteria:

1. allow hooks to set response headers via the context object
2. change onOriginResponse hooks to be applied to a single operation only, allowing for multiple different hooks

Current implementation of on origin response hook

https://docs.wundergraph.com/docs/wundergraph-server-ts-reference/on-origin-response-hook

Solution

The proposed solution below:

// wundergraph.server.ts
export default configureWunderGraphServer<HooksConfig, InternalClient>(() => ({
  hooks: {
    global: {
      httpTransport: {
        onOriginResponse: [{
          enableForOperations: ['MyLoginOperation']
          hook: async ({ response, clientResponse }) => {
            clientResponse.headers.set('Set-Cookie': response.headers['Set-Cookie']);
          },
        }],
      },
    },
  },
}))

It's worth noting, as you might overlook this, that I've made onOriginResponse an array instead of an object.
This means, there can be multiple such hooks, each applied to different operations.

Simpler way

Another option would be to just add a function to the hook context, like setClientResponseHeader(key, value);

[Pagebakers]

The proposed solution looks a bit too complex I think. I would opt for the simpler way, and be able to set the headers in the actual operation hook, it's much better for discoverability and maintainability.

[jensneuse]

The operation hook doesn't allow you to access individual origin response headers.
The post-operation hook only gives you the complete "generated" response from calling all origins according to the execution plan.
Do you have a better idea of how to access response headers from individual origin requests?

[OLingard]

To add another use case for the more complex route, let's say your origin has a GraphQL extensions field with tracking information inside it (trackingId). Without the complex option, you would have to hook into the origin response and log this somewhere on the server. With the option however, you could pass this tracking ID up as a header to allow for greater ease of debugging.

[webcredo]

I think this is a commonly used feature, do you have any plans to implement it?

[jensneuse]

Is it something you'd like to use? I'd love to hear more about your use case.

[webcredo]

Same case as described here #385. Many CMS work this way, so Wundergraph authentication is not needed. Wundergraph would just need to pass on the set-cookie response header and the cookie request header

[jensneuse]

Do you have an example? Are you using such a CMS? When a CMS only supports cookie based auth, how would this work for a native app? With token auth, we'd have a lot more flexibility.

[lubiah]

I'm still facing this problem, @jensneuse , isn't there a solution?