Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recreate WebSocket client when connectionParams change during execution #6335

Closed
enisdenjo opened this issue Dec 6, 2023 · 5 comments · Fixed by #7712
Closed

Recreate WebSocket client when connectionParams change during execution #6335

enisdenjo opened this issue Dec 6, 2023 · 5 comments · Fixed by #7712
Assignees

Comments

@enisdenjo
Copy link
Collaborator

enisdenjo commented Dec 6, 2023

Related #4305 (comment), repro: https://github.com/enisdenjo/graphql-mesh-apollo-sample.

The actual problem why the repro is failing is because the WebSocket instance in Mesh is instantiated during initialisation providing the connectionParams, and then that client instance is used during execution. If this weren't so, each subscription would create a new WebSocket connection itself - which is not ideal.

Provide a way of re-creating the WebSocket instance when the connectionParams change.

@enisdenjo enisdenjo self-assigned this Dec 6, 2023
@ardatan
Copy link
Owner

ardatan commented Dec 7, 2023

How do we decide that connectionParams is changed?

@enisdenjo
Copy link
Collaborator Author

We'd probably have to store it together with the instantiated WS instance. TBH, I haven't thought about it in detail - I just investigated.

@petrepatrasc
Copy link

Hey, we currently use connectionParams as our strategy to ensure that a user is authenticated when interacting with GraphQL subscriptions. Specifically, we pass a JWT token via connectionParams.token, which is then validated in the subsequent service for the GraphQL subscription.

This works well for the first request after starting Mesh and the parameters are proxied correctly, however the connectionParams are then cached for subsequent requests, meaning that Mesh as a whole inherits the session of the first user making the request. Our expectation was that this would behave more similarly to operationHeaders, where the values are passed dynamically.

As I understand from the discussion that @enisdenjo triggered above, this is not currently supported in Mesh, and the current behaviour is to keep the Websocket instance shared.

What would be the right approach then for this workflow? Should user authentication for websocket connections occur before reaching Mesh (i.e. in an API gateway?). Even so, there may be other parameters that need to be sent to the underlying services (i.e. multi-tenancy discriminators) which change per connection.

@perzanko
Copy link

@petrepatrasc We have encountered the same issue. How did you solve it?

@unimonkiez
Copy link

Also have the same issue

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 a pull request may close this issue.

6 participants