Add the ability to use environment variables as HTTP headers when introspecting schemas, etc

[jakemwood]

In our workflow, we are finding ourselves needing to include authorization tokens in the graphql-config.yml file, which can be a security risk since you may accidentally check a token into source control.

This PR allows a user to set an environment variable, called TURMS_HTTP_HEADERS, which would be a JSON object containing the headers they'd like to send along with their requests to their GraphQL server.

You can find examples in the unit tests. I wasn't sure where/if I should document this feature, since there are other environment variables in use that do not seem to be documented in the readme. Happy to document this behavior elsewhere. I also wasn't sure how to format the project, I tried running black but many other changes came along with it. To keep the PR size minimal, I have excluded formatting.

Thanks for your consideration!

[jhnnsrs]

Hi thanks a lot for the PR!

I really need to take some time to update the readme now that the API and configuration format has changed.

And totally agreed that there should be some way of passing additional headers through env variables. I am just wondering if it isbworh keeping the env logic inside the project configuration which should stand as the source of truth for the whole generation? What do you think?

Maybe including an additional headers setting in the config, that has an environmental overwrite?

[enkoder]

@jhnnsrs yes please! This feature is super important as I'm trying to work behind a private api

[deyton]

Hi thanks a lot for the PR!

I really need to take some time to update the readme now that the API and configuration format has changed.

And totally agreed that there should be some way of passing additional headers through env variables. I am just wondering if it isbworh keeping the env logic inside the project configuration which should stand as the source of truth for the whole generation? What do you think?

Maybe including an additional headers setting in the config, that has an environmental overwrite?

hey @jhnnsrs, can you elaborate on how we could keep the env logic inside configuration file? I don't think I understand what it means. Do you mean having a config that specifies which environment variable to look in for header overrides? That way it would be clearer that the headers specified in the config file may not be the ones used. I can update this PR with whatever suggestions you have to make it better 😄

Thanks!

[jhnnsrs]

Hi everyone, sorry wasn't planning on delaying this indefinetely,
I was just hopping that we could use the Project Config BaseModel that is
anyways inheriting from BaseSettings with the env_prefix settings according
to: https://docs.pydantic.dev/latest/concepts/pydantic_settings/#usage

Just looks potentially cleaner and would allow us to come up and inline document
some other environment variables? Generally also happy to include this and then
change strategy later if it is pressing?

Sorry for the holdup.