Closed 0xfourzerofour closed 2 years ago
hello! Could you show the router's logs output? And the configuration file if you use one (scrubbed from any private info of course)?
federation_version: 2
headers:
all:
- propagate:
matching: .*
subgraphs:
esign:
routing_url: https://cwtsl2qxtvb5dkcfj35rlacbci.appsync-api.ap-southeast-2.amazonaws.com/graphql
schema:
file: ./7rr6e2p75ngd3io6mbu2valzh4.graphql
apollo:
routing_url: https://apollo.staging.lawpath.net/graphql
schema:
file: ./fuqqu2ed65czdpsvillyejeqyu.graphql
here is the supergraph file for the router.
the logs did not show any incoming request in the local console but the request was being proxied to the endpoint without authorization as it would give an appsync auth error asking for valid bearer token
2022-05-12T07:17:58.216085Z INFO apollo_router::executable: Apollo Router v0.9.0-rc.0 // (c) Apollo Graph, Inc. // Licensed as ELv2 (https://go.apollo.dev/elv2)
2022-05-12T07:17:58.535501Z INFO apollo_router: starting Apollo Router
2022-05-12T07:17:59.728037Z INFO apollo_router::axum_http_server_factory: GraphQL endpoint exposed at http://127.0.0.1:4000/ 🚀
{
"data": null,
"errors": [
{
"message": "Valid authorization header not provided.",
"locations": [],
"path": null
}
]
}
Hey @joshpauline, It s nice to meet you!
We have cut a release on friday, where we changed the default CORS configuration.
Could you try to give the new release a go? I suspect our CSRF and CORS edits might solve this :)
@o0Ignition0o thanks for getting back to me!
after the update to the new version the requests come through on the console
however the request does not proxy the auth correctly to the appsync endpoint
it still says "Valid authorization header not provided.",
however I know it is correct
Hi, thanks for getting back to us!
Your screenshot allowed me to see I shoudl have logged the "request is preflighted" line in debug mode instead of warn https://github.com/apollographql/router/pull/1058 so thanks for sharing it!
I dug a bit further and the docs mentions we do not automatically propagate hop by hop headers, and Proxy-Authorization is one of them.
What this means is you need to explicitly propagate the header (by name instead of using a regex / *).
Can you give this configuration a try and let us know how it goes?
headers:
all:
- propagate:
matching: .*
- propagate:
named: "proxy-authorization" # this hop by hop header is explicitly propagated
subgraphs:
esign:
routing_url: https://cwtsl2qxtvb5dkcfj35rlacbci.appsync-api.ap-southeast-2.amazonaws.com/graphql
schema:
file: ./7rr6e2p75ngd3io6mbu2valzh4.graphql
apollo:
routing_url: https://apollo.staging.lawpath.net/graphql
schema:
file: ./fuqqu2ed65czdpsvillyejeqyu.graphql
I gave that a go and it looks like it still gives me an error unfortunately
headers:
all:
- propagate:
matching: .*
- propagate:
named: "proxy-authorization"
rename: "authorization"
headers:
all:
- propagate:
matching: .*
- propagate:
named: "proxy-authorization"
I tried both of these. I can see in the network inspector in the studio, there is no header present for proxy-authorization but there is when i use the authorization header instead
Hey @joshpauline it seems you're using a deprecated kind of configuration for subgraphs in this comment https://github.com/apollographql/router/issues/1023#issuecomment-1125481174.
Indeed now if you want to specify another subgraph url than the one specified in your supergraph.graphql
you need to use this configuration https://www.apollographql.com/docs/router/configuration/overview/#subgraph-routing-urls and use override_subgraph_url
. Also no need to specify subgraph schema file, everything should be in the supergraph.graphql
generated file. Let me know if you have questions
@bnjjj isnt that only necessary when you want to override the provided urls that are generated?
enum join__Graph {
APOLLO @join__graph(name: "apollo", url: "https://apollo.staging.lawpath.net/graphql")
ESIGN @join__graph(name: "esign", url: "https://cwtsl2qxtvb5dkcfj35rlacbci.appsync-api.ap-southeast-2.amazonaws.com/graphql")
}
Yes, then in your yaml file you don't need it at all.
Hey @joshpauline
I have just tried to reproduce the issue you've raised with this configuration:
headers:
all:
- propagate:
named: "proxy-authorization" # this hop by hop header is explicitly propagated
- propagate:
matching: .*
and I m running the router with the local example and the docker-compose setup we re usually using:
$ cd /path/to/the/router/repository
$ docker-compose up -d
$ cargo run -- -s ./examples/graphql/local.graphql -c ./propagation-config.router.yml --log trace
The exact curl request I'm running is:
$ curl --request POST \
--header 'apollographql-client-name: ignition' \
--header 'apollographql-client-version: test' \
--header 'content-type: application/json' \
--header 'proxy-authorization: Bearer thisisatestauthheader' \
--url 'http://127.0.0.1:4000/' \
--data '{"query":"query Me {\n me {\n name\n }\n}"}'
I've run the and wireshark sees the headers being sent as:
I have also tried sending a case sensitive Proxy-Authorization
header:
$ curl --request POST \
--header 'apollographql-client-name: ignition' \
--header 'apollographql-client-version: test' \
--header 'content-type: application/json' \
--header 'Proxy-Authorization: Bearer ThisIsACaseSensitiveProxyAuthorizationHeader' \
--url 'http://127.0.0.1:4000/' \
--data '{"query":"query Me {\n me {\n name\n }\n}"}'
Which did propagate:
I also tried to flip the propagation rules:
headers:
all:
- propagate:
matching: .*
- propagate:
named: "proxy-authorization" # this hop by hop header is explicitly propagated
Which worked as well.
Note that in all of the screenshots the host is localhost:4001 so this is effectively a connection being made to the subgraphs.
Can you try to reproduce this locally with the local example and wireshark? Happy to dig further!
@o0Ignition0o thanks for looking into this. I found out the issue. I was using the config file to generate the supergraph schema using rover and then passed the same config into the router params. I just had to remove the subgraphs from the config file and propegate the headers and it works like a charm.
Cheers for being very helpful!
I am able to start the server fine and localhost will redirect me to studio but when i query the endpoint there is an error.
my schema comes from the above appsync request and I am able to successfully compose the supergraph using this
when i pass in the authorization header for my backend services, the error above is what i get. I have tried both Authorization and Proxy-Authorization and neither work.