Is is possible to use express-session for cookie-based authentication?

[pedromsfernandes]

I have a NestJS server and an Apollo client with graphql-ws. I am using cookie-based authentication for my queries and mutations, and now I also need to authenticate the user in my subscriptions. Problem is, in every guide I've seen, only token-based auth is used. I found this issue which provides a solution, however that library is not maintained and as far as I know, graphql-ws onConnect method does not provide a ws argument. Can connectionParams be used for this? Thanks!

[enisdenjo]

Cookies are automatically added to the headers of WebSocket HTTP upgrade requests by the browser.

Authenticate the client the same way you would a regular HTTP request. A great place to do auth is in the onConnect callback, you may find the HTTP upgrade request in the ctx.extra.request.

[pedromsfernandes]

That's what I was missing! Thank you 👍

[Nickersoft]

I recently encountered this thread after having the same question 😅 I noticed though, that the extra field of the onConnect callback context is fully generic: https://github.com/enisdenjo/graphql-ws/blob/master/src/server.ts#L521. If request is always guaranteed to be there, could the type definitions be updated to reflect it? I feel a bit uneasy defining the type in my own code, as I'm not sure if the request will always be attached to the extra field.

[enisdenjo]

When you use one of the use/ servers, the context extra is typed and the documentation is here.

You can also see how makeServer is used for ws.

[Nickersoft]

Ah, got it – yeah I'm using @nestjs/graphql for my GraphQL setup, and it looks like their code just plucks the onConnect type straight out of this package, leaving the generic untyped.

Actually, checking now, as of this writing, the latest issue filed over on that repo mentions the lack of typing around graphql-ws extras, so I'll see if it leads to any movement over there. Thanks for the quick response!

[CemYil03]

Hey, I think I have quite a similar setup. In the background I use express-session but have no idea how to access the session object. I know that my session store executes the reuest correctly, but the response can't be found in the onConnect's context.
This is just the case for @subscription. Mutations and Queries work perfectly.

[CemYil03]

I think I kind of got it to work by placing the session middleware inside of onConnect. But one question that stays open for me is:
The session middleware also sets the session-cookie once a response is sent (so it would need to be able to operate on the response object).

In case of graphql-transport-ws queries and mutations came per regular http request instead of per websocket.
But because with graphql-ws for example the sign in mutation comes in and I can't think of a way how to initialize the session.
Any idea about that?

[enisdenjo]

In case of graphql-transport-ws queries and mutations came per regular http request instead of per websocket.

graphql-ws (subprotocol graphql-transport-ws) is an WebSocket exclusive protocol and library - when using it, everything is transported over WS (queries, mutations and subscriptions).

If you want to run queries and mutations through HTTP, you have to make that split and not use the graphql-ws client.

The session middleware also sets the session-cookie once a response is sent

You cannot set cookies from within an established WebSocket connection. You should instead use regular HTTP requests for the login mutation and set the cookies in the response as you would.

[CemYil03]

Okay thank you, I think this was the thing I had not wrapped my head around yet.
Maybe this would be something to point put in the documentation, so that others don't loose as much time with it.

Summarized: If someone wants only use graphql-ws for his GraphQL-Server and no other kinds of requests, then it is not possible to use session- / cookie-based authentication.

[CemYil03]

To resolve this it would nice to have a configuration option in the createClient method, which allows to still send queries and mutations via http requests and only handle subscriptions via the websocket connection

[enisdenjo]

Maybe this would be something to point put in the documentation, so that others don't loose as much time with it.

Summarized: If someone wants only use graphql-ws for his GraphQL-Server and no other kinds of requests, then it is not possible to use session- / cookie-based authentication.

Sessions around cookies is a HTTP feature, not WebSockets. WebSockets use HTTP only to perform a transport protocol upgrade, after the upgrade is done - all communication happens within the WebSocket connection and not through HTTP.

...configuration option in the createClient method, which allows to still send queries and mutations via http requests and only handle subscriptions via the websocket connection

No, this is a WebSocket library and transport. GraphQL over HTTP is a completely different transport which implements its own specification. You have to make a split when to use HTTP vs. WS yourself.