A Plugin To Manipulate Cookies?

[ajoslin103]

I use the RedwoodJS framework which recently switched to Envelop+Helix

I see there is not an Envelop plugin to help services manipulate cookies

Are cookies available in some other way in my GraphQL services?

Should I write a plugin to help services manipulate cookies?

I feel like I'm missing something - there is no way that I'm the first person to want to manipulate cookies in my gql-services...

[dotansimha]

Hi!
Are you referring to set cookies through the response of the GraphQL result? If you are referring to something like Set-Cookie headers (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) ?

Basically, envelop aims to avoid dealing with things that are specific to your transport, so from envelop point-of-view, it's out of scope.

To address that in a generic way to send headers, I think you can create a simple plugin like that:

const useResponseHeadersPlugin = () => {
  return {
    onContextBuilding({ extendContext }) {
       extendContext({
           responseHeaders: new Set()
       });
    },
    onExecute({ args }) {
       return {
           onExecuteDone({ result, setResult }) {
              // Set headers to be located on `extensions` and later you need to handle it and send it over the HTTP transport
              setResult({ extensions: { ...(result.extensions || {}), headers: args.contextValue.responseHeaders });
             // If you are passing `{ req, res }` to your handler, you can also set it directly on the `res.headers`
           }
       }
    }
  } 
}

Then, in your resolvers, you can do things like:

const resolvers = {
   Mutation: {
      login: (root, args, context) => {
          // ...
          context.responseHeaders.set("X-My-Header", "")
       }
   }
}

Note the comment in the code example: you still need to do some code adjustments in order to send the headers over the network. Either by using res object directly in your plugin, or by using extensions (and then apply extensions to your response).

cc @dthyresson :)

@n1ru4l @ardatan I think maybe in Helix we can pass headers from the response somehow? I know that we have this: https://github.com/contra/graphql-helix/blob/master/packages/core/lib/process-request.ts#L254 , but it seems like it's always empty. I guess it can take results.extensions.httpHeaders or something?

[dotansimha]

We can try to help :)
If reading is the problem - you can just pass the whole req and read it there, no? Envelop doesn't care how your request is being parsed

[ajoslin103]

exactly! yes, that is where I am headed !

I'm trying to wrangle my plugin (which just dumps the context to the console for now) into the RedwoodJS createGraphQLHandler routine that stands up the GQL server

This is the routine in a RedwoodJS project that creates the GQL handler -- all of your declarations [.sdl files] and resolvers are passed in here and we can add our own plugins via extraPlugins

Which are added to the server here: https://github.com/redwoodjs/redwood/blob/main/packages/graphql-server/src/functions/graphql.ts#L186-L189

import { createGraphQLHandler } from '@redwoodjs/graphql-server'

import directives from 'src/directives/**/*.{js,ts}'
import sdls from 'src/graphql/**/*.sdl.{js,ts}'
import services from 'src/services/**/*.{js,ts}'

import { getCurrentUser } from 'src/lib/auth'
import { useRequestHeadersPlugin } from 'src/lib/envelop-request'

import { db } from 'src/lib/db'
import { logger } from 'src/lib/logger'

export const handler = createGraphQLHandler({
  getCurrentUser,
  loggerConfig: { logger, options: {} },
  extraPlugins: [useRequestHeadersPlugin],
  directives,
  sdls,
  services,
  onException: () => {
    // Disconnect from your database with an unhandled exception.
    db.$disconnect()
  },
})

And the basic attempt at a plugin -- to see what's available in context

const path = require('path')
const __file = path.basename(__filename)

// https://www.npmjs.com/package/json-stringify-safe
const stringify = require('json-stringify-safe')

export const useRequestHeadersPlugin = () => {
  return {
    onContextBuilding({ context, extendContext }) {
      console.debug(
        `[${__file}] ~ onContextBuilding() context: ${stringify(
          context,
          null,
          2
        )}`
      )
      // extendContext({
      //   request: context.request,
      // })
    },
  }
}

[ajoslin103]

Ah! I was not instantiating the plugin!

extraPlugins: [useRequestHeadersPlugin],

Should have been

extraPlugins: [useRequestHeadersPlugin()],

Now it's working & I can see the context...

But my services are not receiving the 'context' as expected from the Envelop plugin docs...

So I've got to work something into the Redwood framework to pass the context...

[dthyresson]

Hi @ajoslin103 i replied in the Redwood Discourse forum since you posed the question there — and really I want to know more about what you want to accomplish and why versus how (ie using a plug-in).

https://community.redwoodjs.com/t/how-can-my-services-manipulate-cookies/2550/6?u=dthyresson

Is the cookie you want to manipulate the auth cookie or a different one?

[dthyresson]

Let’s keep the conversation in Discourse for the moment so w can tackle the Redwood use case and then return here if there are any envelop needed tasks.

[ajoslin103]

I solved the problem without needing cookies to flow thru Envelop

Thanks for the pointers, I'll pick this up again should it become a 'something'

[dthyresson]

Btw every Redwood serverless function and service and getCurrentUser has access to the event headers where cookies are found.

[ajoslin103]

doc link?