Altair: Header is not set for subscription

Created on 9 Oct 2018  ·  12Comments  ·  Source: imolorhe/altair

Hi.
I set the header through set headers, and I could see that it is set for graphql query, mutations (POST request). But, with the same session/window, if I try a subscription request, header is not set. If I don't validate the request at server (don't check Auth header), then everything works. That indicates, subscription query from altair is fine except no header set (as i also see through chrome dev tools panel)

thanks.
bsr.

Most helpful comment

Implementing this with the approach defined by apollo graphql subscriptions for the SubscriptionServer, using the onConnect callback to validate the subscription connection request as implemented here.

This is one of a number of approaches used by various libraries but this has the best chance of being the de-facto approach for authentication across GraphQL websocket subscriptions.

All 12 comments

👋🏾Thanks for opening your first issue here! Be sure to follow the issue template! ✌🏾

Thanks for reporting this! I'd look into it as soon as I can.

Just hit this issue myself trying to subscribe to an AWS AppSync API protected with an API_KEY (sent in x-api-key header).

Was hoping that Altair would handle it, as graphql-playground couldn't either.

It appears the underlying websocket connections are handled by subscriptions-transport-ws, googling for that and http headers lead me to the following:

AWS's AppSync doco suggests that it can use the Apollo client, but they provide custom plugins to handle auth/subscription handshakes:

Looking at the custom apollo links implemented in the AppSync SDK we can see that they implement their own header based auth functionality (i'm assuming this also applies to the websocket part.. but not 100%):

So perhaps a similar approach could be leveraged here?

Looking further at the subscription handshake link, it seems that AppSync implements MQTT over the websocket.. so it may not work properly here anyway (opened new issue for this: https://github.com/imolorhe/altair/issues/417):

@0xdevalias Thanks for the contextual information.

@bsr203 How are you using subscriptions with headers?

I have a server (golang) app running on google cloud. So, I was using go standard http package to extract the header, just like POST/ GET request.
I don't know server matters, as the initial ws upgrade POST request from altair doesn't have the header, and I assume it should be like any other POST request.

@bsr203 From the conversation here, https://github.com/apollographql/graphql-subscriptions/blob/master/.designs/authorization.md, It appears you can't set the header in the initial request. Unless I'm missing something.

@imolorhe thanks for the link. Sorry that I guessed it should work with initial POST request. I will look into any of the option which can be implemented outside the HTTP header can be done in my case. thanks again.

My understanding of that is that it depends on where you’re needing to make the request from. But that the standard browser API’s on their own don’t support custom headers for it, so would probably give more headaches down the line.

Given that reason, I’m kind of confused/surprised why AppSync went that way.. I guess since it probably makes use of ApiGateway, and that’s just how it used Auth, so they shoehorned it in..

Edit: Was reading a bit more about AppSync today, and I think it does a few more complex things with websockets for it's subscriptions, doing some handshakes, and potentially connecting to different websockets/endpoints as it goes through, so if support was implemented, it would almost certainly make sense to just use their SDK rather than try and unwind/understand how it all works.

@0xdevalias I'm concerned about implementing this if there is no standard (or near standard) way of handling the authentication. It seems the authentication is handled differently as decided by the developers and the authentication mechanism available to them. If this were to be implemented, what exactly would need to be implemented?

For AppSync, the simplest way would be to use the SDK and have a simple UI or similar way to say ‘this is an AppSync api’, and plug in the appropriate config.

I put together a PoC repo to manually play with it since none of these tools work:

Has notes on how to implement/etc. But basically the main chunk of code is just:

Get Outlook for iOShttps://aka.ms/o0ukef


From: Samuel notifications@github.com
Sent: Friday, October 12, 2018 8:26 pm
To: imolorhe/altair
Cc: 0xdevalias; Mention
Subject: Re: [imolorhe/altair] Header is not set for subscription (#416)

@0xdevaliashttps://github.com/0xdevalias I'm concerned about implementing this if there is no standard (or near standard) way of handling the authentication. It seems the authentication is handled differently as decided by the developers and the authentication mechanism available to them. If this were to be implemented, what exactly would need to be implemented?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/imolorhe/altair/issues/416#issuecomment-429264007, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAuA4y872mf1f1l6IS_kYnXXJvLzy9M-ks5ukGBTgaJpZM4XTwUY.

Implementing this with the approach defined by apollo graphql subscriptions for the SubscriptionServer, using the onConnect callback to validate the subscription connection request as implemented here.

This is one of a number of approaches used by various libraries but this has the best chance of being the de-facto approach for authentication across GraphQL websocket subscriptions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

HitkoDev picture HitkoDev  ·  6Comments

aoudiamoncef picture aoudiamoncef  ·  5Comments

someden picture someden  ·  9Comments

XAKEPEHOK picture XAKEPEHOK  ·  8Comments

trafficfox picture trafficfox  ·  8Comments