Azure-docs: This doesn't deal with HTTPS

[JohnGalt1717]

This document doesn't deal with how to make ASP.NET Core handle HTTPS properly. If you set it up in the web service, then yes, https works, but asp.net believes it's running as plain old http, which it freaks out about in multiple locations like Swagger, and OpenIdConnect. It needs to be clearly documented how to get aspnet core kestrel that's running in the docker container to handle https properly and have the web app pass through, or make kestrel THINK it's running in https behind a proxy properly.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8460864c-a2ad-b8e5-d1fc-6135a30edfdc
• Version Independent ID: 43f15878-2497-ca3a-324b-9f4b2e9c76dc
• Content: Create a .NET Core web app and deploy to App Service on Linux
• Content Source: articles/app-service/containers/quickstart-dotnetcore.md
• Service: app-service
• GitHub Login: @cephalin
• Microsoft Alias: cfowler

[BryanTrach-MSFT]

@JohnGalt1717 Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

[JohnGalt1717]

Great! I think the answer is burried in other documentation about reverse proxies but it should be front and center with the specific settings required to make it work for azure web containers.

[cephalin]

@JohnGalt1717 We can add a link to https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-2.1. To clarify on your last comment, front-end load balancer is standard to App Service and not just containers.

[cephalin]

https://mseng.visualstudio.com/TechnicalContent/_workitems/edit/1300885

[JohnGalt1717]

@cephalin That isn't sufficient. The instructions on that page will not actually work with Azure Containers. You need ALL of the following:

`
var forwardOptions = new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto,
RequireHeaderSymmetry = false
};

        forwardOptions.KnownNetworks.Clear();
        forwardOptions.KnownProxies.Clear();

        app.UseForwardedHeaders(forwardOptions);

`

[cephalin]

@JohnGalt1717 Thanks a lot for this information. We'll look into this. Most likely we'll need the same type of information for all language frameworks.

[pwen090]

Clearing KnownNetworks and KnownProxies is bad for security. How do we programmatically get the right addresses to use with Azure App Service for Linux?

[nelfer]

Hi,
I'm having issue with the app not recognizing that is running under HTTPS, like when following this tutorial:
https://azure.microsoft.com/en-us/resources/samples/active-directory-dotnet-webapp-openidconnect-aspnetcore/

It doesn't work once published to an Azure Web App (Linux), because the container receives the Request.Schema as "http" instead of "https". And so when it creates the redirect URL, it is something like "http://myapp.azurewebsites.net". Azure requires HTTPS for authentication reply URLs, producing an error that reply URL doesn't match.

Is there an official solution for this? I hear some concerns about clearing KnownNetworks?

[cephalin]

@JohnGalt1717 This is now documented at https://docs.microsoft.com/en-us/azure/app-service/containers/configure-language-dotnetcore. #please-close

[JohnGalt1717]

Looks good! That will help a lot of people!