Provide a way to set the fetch() options in generatePossibleTypes

[justlevine]

What

There should be a way to filter the options on the fetch() call in generatePossibleTypes(), in order to set things like cors mode, and headers.

Why

I am trying to generatePossibleTypes() from my localhost, but I have a CORS policy set on WordPress to limit Access-Control-Allow-Origin to a fixed list of domains (e.g. [mysite.com, staging.mysite.com, localhost:3000]).

For that to work I need to change the fetch() call to:

const response = await fetch(GRAPHQL_ENDPOINT, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Origin: 'http://localhost:3000',
  },
  mode: 'cors',
  referrerPolicy: 'origin-when-cross-origin',
  body: ...
}

Alternatives considered.

I can create a custom 'generatePossibleTypes()'. The barrier to entry on this is fairly high, as users expect Faust to 'just work'.

[theodesp]

Hey @justlevine . I had the impression that CORS should not interfere with server-to-server (host-to-host) requests. Since the request here uses isomorphic-fetch, it should happen on the between the host machine (not a Browser) and your WPGrahpQL endpoint(the server).

So in that case the Access-Control-Allow-Origin is ignored.

You can easily test this locally using the following scripts:

const http = require('http');

const server = http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'https://mysite.com');
  res.setHeader('Content-Type', 'application/json');
  res.write(JSON.stringify({ message: 'Hello, world!' }));
  res.end();
});

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

$ node server.js
Server listening on port 3000

import fetch from 'node-fetch';

fetch('http://localhost:3000/')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error(error));

❯ node client.mjs
{ message: 'Hello, world!' }

❯ curl http://localhost:3000/ -v
*   Trying 127.0.0.1:3000...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET / HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: https://mysite.com
< Content-Type: application/json
< Date: Mon, 17 Apr 2023 11:21:46 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
< 
* Connection #0 to host localhost left intact
{"message":"Hello, world!"}% 

So there is nothing preventing the request from happening. You can perform the introspection request right from your CLI without issues:

curl 'http://mysite.local/index.php?graphql' \
  -H 'content-type: application/json' \
  --data-raw '{"operationName":"IntrospectionQuery","variables":{},"query":"query IntrospectionQuery {\n  __schema {\n    queryType {\n      name\n      __typename\n    }\n    mutationType {\n      name\n      __typename\n    }\n    subscriptionType {\n      name\n      __typename\n    }\n    types {\n      ...FullType\n      __typename\n    }\n    directives {\n      name\n      description\n      locations\n      args {\n        ...InputValue\n        __typename\n      }\n      __typename\n    }\n    __typename\n  }\n}\n\nfragment FullType on __Type {\n  kind\n  name\n  description\n  fields(includeDeprecated: true) {\n    name\n    description\n    args {\n      ...InputValue\n      __typename\n    }\n    type {\n      ...TypeRef\n      __typename\n    }\n    isDeprecated\n    deprecationReason\n    __typename\n  }\n  inputFields {\n    ...InputValue\n    __typename\n  }\n  interfaces {\n    ...TypeRef\n    __typename\n  }\n  enumValues(includeDeprecated: true) {\n    name\n    description\n    isDeprecated\n    deprecationReason\n    __typename\n  }\n  possibleTypes {\n    ...TypeRef\n    __typename\n  }\n  __typename\n}\n\nfragment InputValue on __InputValue {\n  name\n  description\n  type {\n    ...TypeRef\n    __typename\n  }\n  defaultValue\n  __typename\n}\n\nfragment TypeRef on __Type {\n  kind\n  name\n  ofType {\n    kind\n    name\n    ofType {\n      kind\n      name\n      ofType {\n        kind\n        name\n        ofType {\n          kind\n          name\n          ofType {\n            kind\n            name\n            ofType {\n              kind\n              name\n              ofType {\n                kind\n                name\n                __typename\n              }\n              __typename\n            }\n            __typename\n          }\n          __typename\n        }\n        __typename\n      }\n      __typename\n    }\n    __typename\n  }\n  __typename\n}"}' \
  --compressed \
  --insecure

[justlevine]

@theodesp the reason why the origin header isn't set automatically is because of CORS, but Access-Control-Allow-Origin can be used by the server to restrict any http request, not just ones from the browser.
As far as I can tell, WPGraphQL has no way to discern whether a request is coming from a browser or server. If you want to limit your WPGraphQL endpoint to only a list of authorized domains (be it with a built in filter or either the WPGraphQL CORS / WPGraphQL Headless Login plugins), you will see faust generate no longer works.

Another use case is if you've restricted the entire endpoint to authorized requests only (a core WPGraphQL setting), and therefore need to set an authorization header.

[theodesp]

I think this is a very undocumented feature since most examples mention Browser to Server interactions.
I mean TBH if your server wanted to block an Origin they could check different things like Host, IPs' or whatever.

Origin can be easily spoofed from a client outside of a browser environment but cannot be spoofed by a browser.

So my suggestion here is to no to use CORS as a security mechanism since it's more confusing. I'm open to further suggestions though.

[justlevine]

To clarify before you close this out, my feature request here is to allow the fetch call in generatePossibleTypes to be configurable by the user.

I then gave two use cases:

• users who have set Access-Control-Allow-Origin in WPGraphQL, either using WPGraphQLs filters or via one of two extensions (that I'm aware of), and therefore need an Origin.
• users who have limited their GraphQL endpoint to authorized requests only.

Both of these use cases currently break generatePossibleTypes().

So my suggestion here is to no to use CORS as a security mechanism since it's more confusing.

Whether WPGraphQL should or even can be changed to support differentiating between client/server requests is a much larger conversation, but I think from the perspective of Faust, we should care about current behavior (it currently fails, and user expectation of WPGraphQL CORS 'Limit unauthorized requests' is that it should fail, be it from a browser, an app, or a a node cli command ).

If we don't care, the same there's still the auth use case to support this feature request.

[theodesp]

Since this is a CLI command I wonder how it will look like:

--fetch-options, -H       additional fetchOptions (in JSON format)
--fetch-options-file, -f   JSON file of additional fetchOptions

faust generate -H '{"headers": { "X-Hello": 'World!' } }'

or

faust generate -f headers.json

[justlevine]

What about if we use faust.config.js? Has all the pros of the second option (ie not having to write error-prone inline JSON), but without the need for an extra file.

Plus it would let us take advantage of type safety, and is a much more future-proof pattern as FaustJS continues to iterate.

(Edit: It also could make some of the ApolloClient/auth improvements I've been lobbying for DRYer to implement because the cli and the client headers could theoretically be defined via the same config file).

Separately I think being able to pass a custom faust.config to any faust cli command would be a welcome addition, if it's not already supported.

[theodesp]

Will move this to ideas discussion board.