remote schema subscription proxy with auth

[greenreign]

I have a schema that proxies some operations to a remote schema. This includes subscriptions. I am upgrading to graphql-ws and therefore apollo 4. We are following the pattern here with executors:
https://the-guild.dev/graphql/tools/docs/remote-schemas#hybrid-graphql-over-http-and-graphql-over-websocket-graphql-ws

Every operation that comes through the main service will pass in an authorization token. Even for subscriptions. This token must be proxied through to the remote schema in order for the subscriptions to succeed. I don't see a way to pass through the authorization header to the remote schema.

const subscriptionClient = createClient({
    url: process.env.WS_URL,
    webSocketImpl: WebSocket,
});

It would seem I should use connectionParams above but the params are not static. Each execution would need to inject its params. In the past (subscriptions-transport-ws) the SubscriptionClient allowed middleware

subscriptionClient.use([addAuthParamsMiddleware])

where we had access to the context and could add properties to options that were passed along.

In the executor I have access to the context but do not see a way to set them into an object that will be passed to the remote schema. Currently I've hacked them into the extensions object but I'm sure that's not appropriate. I'm wondering what is the correct approach for this pattern. In all the relevant examples the token is either static or can be generated with no other context. In my case this client is a relay and just needs to pass along what is passed in. Would it be more appropriate to have a SubscriptionClient per execution? Creating the client in the executor where I have access to the context?

const wsExecutor: AsyncExecutor<PermissiveContext> = async (options) => {
    const { document, variables, operationName, extensions } = options;
    return observableToAsyncIterable({
        subscribe: (observer) => {
            return {
                unsubscribe: subscriptionClient.subscribe(
                    {
                        operationName,
                        variables,
                        extensions: ext,
                        query: print(document),
                    },
                    {
                        next: (data) => observer.next?.(data as unknown),
                        error(err: any) {
                            if (!observer.error) { return; }
                            if (err instanceof Error) {
                                observer.error(err);
                            } else if (!_.isNil(err?.['code']) && !_.isUndefined(err?.['wasClean'])) {
                                observer.error(new Error(`Socket closed with event ${err.code}`));
                            } else if (Array.isArray(err)) {
                                observer.error(new Error(err.map(({ message }) => message).join(', ')));
                            }
                        },
                        complete: () => observer.complete?.(),
                    },
                  ),
            };
        },
    });
};

[enisdenjo]

If you need a different token for each execution, then the extensions field is the way to go. This would be the most effective, and spec compliant, approach of connecting a token to an operation.

If my understanding is not flawed, this is exactly what the middlewares do in subscriptions-transport-ws, they inject/modify the operation execution parameters (see here).

[greenreign]

Awesome, thanks!