him we are trying to add subscription (now that we...
# graphql-kotlin
n
him we are trying to add subscription (now that we got websockets to go through the google cloudrun) and it seems we are running into a few weird issues whenever there is any issues (syntax or such) it returns
Copy code
{
  "error": "Could not connect to websocket endpoint <ws://localhost:8080/subscriptions>. Please check if the endpoint url is correct."
}
not sure if this is a issue in plaground or in the library however and seems like the
GraphQLContextFactory
does not kick in for subscriptions so we cannot figure out how to get access to Header
Authorization
for subscriptions currently
d
are you using
spring-server
or your own implementation?
as for the
Authorization
header -> in current released version of
spring-server
context is created in a
WebFilter
(same way as for queries/mutations). Maybe this is related to https://github.com/ExpediaGroup/graphql-kotlin/discussions/975? side note -> we recently abstracted away execution logic to avoid the need for the webfilter which should simplify this (not yet released)
n
do i need a
SpringSubscriptionGraphQLContextFactory
then ? we are currently using a
GraphQLContextFactory
i assume that is on the latest snapshot, or only in master ? then i might have to use mavenLocal()
also we do not use spring-security .. so i am not sure how much it applies
d
SpringSubscriptionGraphQLContextFactory
is on latest snapshot (should be releasing another alpha soon)
which may be related as well
n
now i build master locally and i am using
SpringSubscriptionGraphQLContextFactory
but in the
generateContext
call i do not get the header
d
how are you setting the header
n
sending in via playground or ktor client

https://nikky.catgirl.host/i/cumht626.png

d
is it on whole request or included in WS subscription message
n
thats what i am trying to figure out myself.. would suck if playground could not be used
d
afaik headers are not really common in websockets so might be the case
n
seems like playground does not set the header on /subscription and i have been barking up the wrong tree
i guess i will have to test with ktor client
d
not an expert on subscriptions so there might be some issues
n
okay yes.. it works.. except not through playground, so gonna report the bug there and wait for the current start of graphql-kotlin/master to be released as a alpha
d
i think playground is deprecated….
did they ever got around releasing graphiql version?
n
if there is a newer better thing, will it be bundled in graphql-kotlin-spring-server like playground currently is ? .. or is that the new thing already ?
d
yeah we’ll update it once graphiql version is released (need to check whether it already was)
n
i see.. i am currently browsing to see if there is any kind of release just the like https://github.com/ExpediaGroup/graphql-kotlin/blob/master/servers/graphql-kotlin-spring-server/src/main/resources/graphql-playground.html its like these people only design it to be bundled within some other web thingy
d
fyi there are tons of different tools like playground - altair or voyager to name a few
n
i have been trying a few of them.. seems like none of them do headers on subscriptions.. but headers on normal queries and mutations are a feature..
j
Agree that subscriptions and auth are a bit of wild west. We've gotten them to work in our opinionated dropwizard+graphql-kotlin framework as follows: • add a reference to a
Principal?
to our GraphQLContext implementation • In the GraphQL websocket upgrade, check the user principal from dropwizard auth and put it in the context (optionally rejecting all unauthenticated websocket upgrades with a 401) • use a service-hosted graphiQL with subscription support. Putting that behind the same auth gate as the graphql endpoint makes the browser prompt for auth when hitting graphiQL, and then re-use the creds when hitting the graphql endpoint when we're using Basic auth. token based auth may or may not complicate things from a usability point of view • In graphql resolver functions, inject the GraphQLContext and check the principal as needed (minimal test example that refs the principal but doesn't actually do much) Most of this should be replicable in graphql-kotlin's spring implementation, but not sure how much would be included out of the box
s
In
graphql-kotlin-spring-server
you can implement the
ApolloSubscriptionHooks.onConnect
to modify the context https://github.com/ExpediaGroup/graphql-kotlin/blob/335f857c5496679723ae76ceba26cc[…]/graphql/server/spring/subscriptions/ApolloSubscriptionHooks.kt
n
thanks, that worked like a charm