apollographql / router

A configurable, high-performance routing runtime for Apollo Federation 🚀
https://www.apollographql.com/docs/router/
Other
808 stars 272 forks source link

error in local setup #1023

Closed 0xfourzerofour closed 2 years ago

0xfourzerofour commented 2 years ago

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.

Screen Shot 2022-05-12 at 4 20 56 pm

 #!/usr/bin/env bash

apis=$(aws appsync list-graphql-apis --query 'graphqlApis[*].apiId' --output text)

for api in $apis; do

  aws appsync get-introspection-schema --api-id $api --format SDL --no-include-directives $api.graphql
done

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.

{
  "name": "TypeError",
  "message": "Failed to fetch",
  "stack": "TypeError: Failed to fetch\n    at https://cdn.ravenjs.com/3.22.1/raven.min.js:2:11497\n    at https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:149424\n    at Generator.next (<anonymous>)\n    at https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:133045\n    at new Promise (<anonymous>)\n    at mr (https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:132790)\n    at https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:148996\n    at https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:150059\n    at Generator.next (<anonymous>)\n    at i (https://studio-ui-deployments.apollographql.com/build/static/js/ExplorerPage.abaac949274eaf3706fd.js:2:140061)"
}
Geal commented 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)?

0xfourzerofour commented 2 years ago
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/ 🚀

Screen Shot 2022-05-13 at 8 41 55 am

{
  "data": null,
  "errors": [
    {
      "message": "Valid authorization header not provided.",
      "locations": [],
      "path": null
    }
  ]
}
o0Ignition0o commented 2 years ago

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 :)

0xfourzerofour commented 2 years ago

@o0Ignition0o thanks for getting back to me!

after the update to the new version the requests come through on the console Screen Shot 2022-05-16 at 7 09 33 pm

however the request does not proxy the auth correctly to the appsync endpoint

Untitled.pdf

it still says "Valid authorization header not provided.", however I know it is correct

o0Ignition0o commented 2 years ago

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
0xfourzerofour commented 2 years ago

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

bnjjj commented 2 years ago

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

0xfourzerofour commented 2 years ago

@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")
}
bnjjj commented 2 years ago

Yes, then in your yaml file you don't need it at all.

o0Ignition0o commented 2 years ago

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:

image

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:

image

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!

0xfourzerofour commented 2 years ago

@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!