Auth seems to be a big sticking point, as mentioned in several issues:
https://github.com/apollographql/subscriptions-transport-ws/issues/33
https://github.com/apollographql/subscriptions-transport-ws/issues/75
I am starting to encounter pain with auth, myself. I am building a react-native app where I need to be able to connect the WS only after the user is authenticated to protect the WS server.
Right now, on our web app, I am passing a JWT token (if available) into connectionParams and then parsing that token server side... rejecting the connection if the token isn't present or is invalid or belongs to a user who should no longer be able to access our product. This works well for our current build, because we set a cookie and do full page refresh after and so we get a "fresh" network interface that has the ws transport applied to it whenever the token cookie is present.
However, with react native, I can't simply "refresh", nor do I really want to as I want to experience to feel fluid as most mobile apps feel.
I need a way to conditionally connect with a dynamic connection param at the time that the user finishes logging in or registering.
My proposal is that we should modify connectionParams to accept either an object (as is) or a function that returns an object. If connectionParams is a function, the connect call in the SubscriptionClient constructor is skipped and lazily invoked on the first subscribe call. This would satisfy my case, because I don't reach code that attempts subscriptions until the user is in a state of authentication.
I would like to submit a PR for this tomorrow. This is a huge blocker for me right now.
Thanks!
Thank you for this work @thebigredgeek. I have exactly the same need as you (but for angular-apollo client).
connectionParams as a function is a nice way of solving this. When your credentials are updated, we would need to call close on SubscriptionClient. It will reconnect automatically with the new credentials from connectionParams and the context will be updated on the server side only for the connections initialized with reconnect: true. It would not be an issue for me but do you think it could be ?
@hmlb for my own use case, I don't need a WS connection until after the user has been authenticated... and this is probably best practice in terms of WS security. The lazy flag causes the interface to not attempt a WS connection until the first subscribe call is made, which means there is no need to close/reconnect.
That's fine. I now use your fork of SubscriptionClient and it works perfectly for the lazy (post login) first connection, and for my more specific use case of different levels of authorization where I need to close/reconnect for the same user.
Thanks !
@hmlb hopefully we can get the design change approved soon. I'll finish up by writing tests and docs once that is done. Also currently using my fork :D
Merged and available in 0.7.0! Thanks @thebigredgeek
Most helpful comment
Merged and available in 0.7.0! Thanks @thebigredgeek