Add an option to force the protocol and hostname used by the playground

[sandorfr]

Is your feature request related to a problem? Please describe. Currently the playground infers the request from the incoming request. https://github.com/ChilliCream/hotchocolate/blob/7cc3094243fa8500c87ab134c36233567e4ada6e/src/Server/AspNetCore.Playground/SettingsMiddleware.cs#L69

The problem is that when it's hosted behind a ssl termination point (thing application gateway, frontdoor on azure for instance) the server will see the request as http (and with a different hostname in some cases). So the requests to the graphql endpoint will fail (because they'll try to make a request over http instead of https).

Describe the solution you'd like It would be good to be able to override the default behavior via a setting.

Describe alternatives you've considered Not using the playground, and relying on the electron app or hosting the playground somewhere else (requires cors to be properly configured).

[michaelstaib]

It would be good to be able to override the default behavior via a setting.

Can you detail more what you would like to have here?

[michaelstaib]

Not using the playground, and relying on the electron app or hosting the playground somewhere else (requires cors to be properly configured).

If the electron app is correctly configured than it will ignore cors.

Still we should fix the playground middleware. If you could detail more what you would like to change this would be great.

[sandorfr]

Can you detail more what you would like to have here?

A simple PlaygroundOption

app.UsePlayground(new PlaygroundOptions
{
      GraphQLEndpoint = "https://my-public-facing-endpoint.com"
});         

Also I assume that other UIs (voyager and graphiql) might have the same issue.

[TomBruyneel]

This would be nice, my site is behind an enginex instance that handles the https. This breaks the playground as it still tries to load the graphql data from the http endpoint

[NiebylskiM]

I have the same problem with Voyager hosted on ASF cluster. Would be nice to have that option to override server URL, otherwise I'm not able to use Voyager at all.

[michaelstaib]

Anybody wants to implement this than we could package it up with the next hotfix.

The target branch for this is: version_10_0_0_master

[michaelstaib]

@NiebylskiM this one os not implemented for version 11 we are also fixing it for 10.4.1.

Awesome work @tomphilbin

[TheJayMann]

I am just now noticing this, but, is there any reason, at least with ASP.NET Core, that you couldn't make use of the XForwardedFor options? By default, when IIS integrations are used, if the request is coming from localhost, there is an ASP.NET Core middleware which looks for various X-Forwarded-* headers and rebuilds the URL in the request. For other reverse proxies, this middleware can be configured as necessary.

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.1

[michaelstaib]

@TheJayMann this would be actually great to integrate. Do you want to do a pull-request?

[TheJayMann]

This isn't exactly something to integrate into HotChocoloate, but, rather, the correct way to configure ASP.NET Core when you plan to host ASP.NET Core behind a reverse proxy. In other words, something you would configure separately from HotChocolate.

It is also something that would be configured differently for each person hosting their web site. In ConfigureServices, you would have something similar to this.

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardLimit = 2;
    options.KnownNetworks.Add(IPAddress.Parse("10.0.0.0"), 8);
});

Then, in Configure, as the first (or near the first) middleware to add, use the UseForwardedHeaders() extension method.

Finally, make sure the reverse proxy is adding the X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host (or, that the reverse proxy has the Host header passed through).

With all this configured, the forwarding middleware will automatically update the Request property of the HttpContext to the values provided by the X-Forwarded-* headers.

[michaelstaib]

@TheJayMann thanks for sharing this. We have to write up something on this so that we can help people better since a lot of people ran into that issue.

@PascalSenn FYI

[michaelstaib]

I moved this to 11 so that we include documentation on this.

[michaelstaib]

We have now replaced playground with bcp and are using the new endpoint routing.