-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Header is not set for subscription #416
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 Was hoping that Altair would handle it, as graphql-playground couldn't either. It appears the underlying websocket connections are handled by
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: #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. |
@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:
* https://github.com/0xdevalias/poc-aws-appsync
Has notes on how to implement/etc. But basically the main chunk of code is just:
* https://github.com/0xdevalias/poc-aws-appsync/blob/master/src/index.js#L7,L63
Get Outlook for iOS<https://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)
@0xdevalias<https://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 GitHub<#416 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAuA4y872mf1f1l6IS_kYnXXJvLzy9M-ks5ukGBTgaJpZM4XTwUY>.
|
Implementing this with the approach defined by apollo graphql subscriptions for the SubscriptionServer, using the 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. |
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.
The text was updated successfully, but these errors were encountered: