Propagating Downstream Response Headers (set-cookie) to the Wundergraph Reponse

[OLingard]

Problem

Hi Wundergraph! Our downstream client uses cookie based authentication where, on a successful login mutation, they pass a set-cookie header in the response with the auth token.
With this flow, we would need to pass this header upto the client but I'm not seeing anywhere to do this. With request headers it's simple as we can specify to pass them in the introspect.graphql options but there's no option for response headers.
My other thought was to hook into the originResponse however I'm not sure how I can use this hook to mutate the final response.
Can this be done?

Suggested solution

Similar to passing request headers in the graphql introspection, can we also add response headers in the same section? There's complications to this due to a Wundergraph query potentially making multiple requests to the downstream api. We could add an enum with values of collate and overwrite so that the former would add all the values of the header in question to a comma-delimited string whilst the latter just chooses the last value set. Not too much thought has gone into the above though so there might be stumbling blocks.

Additional context

My downstream response headers:

Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: Opaque_token=aaa-bbbccc000ddd111eee222fff333-; Path=/; Domain=www.testdomain.com; Expires=Tue, 30-May-2023 13:14:20 GMT; Max-Age=15552000; Secure; HttpOnly
Strict-Transport-Security: max-age=31536000
Vary: Origin
Vary: Accept-Encoding
X-Content-Type-Options: nosniff

The response headers on the Wundergraph response:

HTTP/1.1 200 OK
Content-Type: application/json
Vary: Origin
Date: Thu, 01 Dec 2022 13:14:20 GMT
Content-Length: 119

[jensneuse]

What are your thoughts on this:

The "Set-Cookie" request comes back.
You can use a post origin response hook to store the cookie Header somewhere, e.g. in a database (per user or per anything).
Next, you configure to send a header named cookie to the origin (in the data source), and you set it to "X-Cookie" (from the client request).

This X-Cookie will never be set from a client request, so we don't send it to the origin.
Now, we can use a hook to set the previously stored cookie to requests to this origin.

All of this means that cookies for this never need to get back to the client.
All we do is store them server side per user.
As authentication is already implemented, this will more or less just work.

What are your thoughts?

[OLingard]

Hey Jens, a few issues with this in my eyes:

• Once we store the cookie, a user would have to then be identifiable again to access the cookie. Without passing a id token or something similar back to the client this feels impossible. If we need this id token, isn't this the same as passing the response header back to the client?
• Setting Cookies from the server is a common flow (for Authentication or otherwise) and if we look at the additional steps needed for this:
  • Database Creation
  • Handling of expiry dates
  • Invalidation of cookie values
  • etc
    The list is pretty large.

Is the issue here that only returning the body and not the response headers is supported in the graphql-go-tools package?

[jensneuse]

No, it's not an issue. I'm just trying to find the best possible solution.
Are you using WunderGraph authentication (cookie or token-based)?
If not, it seems like you're looking at just proxying the user identity to the origin,
so having a way of sending back a response header would be feasible.

[OLingard]

We're not using Wundergraph authentication right now. You're correct with the later point, authentication would solely be handled by the origin service. Wundergraph would just needs to pass on the set-cookie response header and the cookie request header (the latter is easily done).

[jensneuse]

Let me know your thoughts on this one: #389

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.