Closing the connection based of subscription and token

[alexsserban]

Hello,

Graphql-ws works great so far but I have a question regarding authentication.

My setup is apollo express server + Graphql Shield for setting up permissions. I've gone through your recipes for custom context value and I am able to send my user data from a token to GraphqlShield.

The scenario is this... I have two different subscriptions: one allowed only for LoggedIn Users, and one allowed only for Admin Users... the difference between those two roles is in the authorization token.

The permission aspect of the setup works good.... GraphqlShield receives the userData from GraphqlWS and takes the necessary measures.

When a user is declined from GraphqlShield, the WebSocket connection is not terminated tho. First of all, is that a problem in terms of security or anything else? If so, how should I be able to terminate the connection? In onConnect and onSubscribe I can't (or I don't know how) verify which of the two subscriptions is being used so I can't close the connection if I want.

[enisdenjo]

Sadly I am not familiar with GraphqlShield or its inner workings, so I cannot help in that regard. However, I can tell you that you can indeed terminate the connection from within any callback using the ctx.extra.socket. Please consult the server-side "ws server and client auth usage with token expiration, validation and refresh" recipe for an exact example.

[alexsserban]

Ok, letting aside the GraphqlShield part and considering that I read that specific recipe, what I need is to be able to make the server decide if to terminate the connection not only on the validity of the token (as shown in the recipe) but also based on the user role (extracted from the token) in relation to the subscription used. Basically, I want to deny access to a subscription to the normal logged-in User and allow it only for logged Admins while I need to have another subscription that grants access to both types. of users.

[enisdenjo]

You can still use the same flow as in the recipe, just replace/add in addition to isTokenValid a check canUserAccess. Depending on where you want the restriction checks, choose the right callback: onConnect, onSubscribe or onNext or any other.

Additionally, the schema server option can be a function that returns a Promise, you may alter the schema itself depending on the user type there too. Since all callback server options have the ctx argument, you can call ctx.extra.socket.close() from there too. Please find a concrete example in the "ws server usage with dynamic schema" recipe.

[alexsserban]

That is what I was looking for, thank you a lot for your help, it was my mistake that I didn't see that in the callbacks I have the message parameter, I was thinking I only have the ctx parameter.

I have one other question if you can help: The overall schema that I use with ApolloServer is getting larger and larger, but I have only 2 subscriptions. Does it makes sense (and has any drawbacks?) to send my complete schema with all of my queries and mutations to GraphqlWS useServer function, or it is a better practice to create a different schema from my main one, which only consists of the things needed for subscriptions to work?

[enisdenjo]

Glad you figured it out!

About the schema, I really have no opinion there. I personally always pass the whole schema to graphql-ws. My rule of thumb for everything is: measure three times, cut once. Meaning, test the behavior and performance of a separate schema vs. the current monolithic one first and decide from there.

I dont think there will be a noticeable difference though; and, as long as there is no noticeable difference - separating the schemas is just a phantom optimization step that will eventually become an unnecessary maintenance liability.

[alexsserban]

Thanks for all the fast responses, that clarifies it.