Azure WebApp: Scheme not set to HTTPS, breaks RequireHttps and OAuth/OIDC

[LeandroPT]

I have an RC2 Application running on Azure Web App Role.

on the browser side:
https://mydummycisiteci.azurewebsites.net redirected you too many times.

On the stdout log for aspnetcoremodule:

info: Microsoft.Extensions.DependencyInjection.DataProtectionServices[0]
      Azure Web Sites environment detected. Using 'D:\home\ASP.NET\DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Production
Content root path: D:\home\site\wwwroot
Now listening on: http://localhost:15934/
Application started. Press Ctrl+C to shut down.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://mydummycisite.azurewebsites.net/  
warn: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Authorization failed for the request at filter 'Microsoft.AspNetCore.Mvc.RequireHttpsAttribute'.
info: Microsoft.AspNetCore.Mvc.RedirectResult[1]
      Executing RedirectResult, redirecting to https://mydummycisite.azurewebsites.net/.

The most interesting fact is that if if download a resource (image for example)

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1] Request starting HTTP/1.1 GET http://mydummycisite.azurewebsites.net/favicon.ico info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2] Request finished in 1227.537ms 404

on the browser side:
http://mydummycisite.azurewebsites.net/favicon.ico Failed to load resource: the server responded with a status of 404 (Not Found)

I have the exact same configuration on Local IIS and works like a candy...

web.config - Azure App

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="D:\home\Microsoft\dotnet\cli\dotnet.exe" arguments=".\..\approot\mydummycisite.dll" stdoutLogEnabled="true" stdoutLogFile=".\..\logs\stdoutcm" startupTimeLimit="3600" />
  </system.webServer>
</configuration>

Am i doing something wrong, or AspNetCoreModule still in the forge in Azure?

[muratg]

I don' think AspNetCoreModule is available on Azure App Service yet. @shirhatti?

[LeandroPT]

@muratg @shirhatti

It didn't complain about the module... As you can see by the log file... and process explorer shows it running dotnet.exe...

[moozzyk]

This is fishy... If AspNetCoreModule had not been installed the application would not have been started... You would get 502 or something to this effect.

[muratg]

Ah, perhaps the App Service roll out is completed after all.

[LeandroPT]

@moozzyk @muratg

Yeah, but why no response to browser? Request get to kestrel, response is return from kestrel... why no reach the browser? Will @shirhatti have an idea?

[muratg]

@BrennanConroy is giving this a try... @LeandroPT I assume you're using a simple HelloWeb or HelloMvc app?

[LeandroPT]

@muratg

No.. My RC2 MVC app. But you guys can check with those, all i need is confirmation that is ready. As you saw by the posts in this, i assumed it was not installed too.

I tested with both netcoreapp1.0 (the config above) and a net451 .exe
Both have the same outcome.

What i find weird is the HTTPS not beeing passed along. The same config (both frameworks) work just fine in local IIS server.

[shirhatti]

@muratg Azure App Service performs a rolling deployment. I believe they are currently in the process of rolling out ANCM. YMMV till they finish their deployment.

[LeandroPT]

@shirhatti

You abbreviations almost killed me... Where can that progress be tracked?

[BrennanConroy]

What is your actual issue?
ANCM is being deployed so some Web Apps may have it and others might not. In your case you have it 👍

[BrennanConroy]

No reply, closing

[LeandroPT]

@BrennanConroy

The issue still remains and the answer to your question is on the 1st post, and my life is already complicated to have you set me SLA's for replies.

I did some more tests and this is what i found out:

Picked project IISSamples on this repository as of TODAY, tweaked the project.json
project.json.txt

:

Running in LOCAL IIS: https://localhost:4431/

Hello World - 27/04/2016 12:13:59 +01:00

Address:
**Scheme: https**
Host: localhost:4431
PathBase: 
Path: /
Query: 

Connection:
RemoteIp: ::1
RemotePort: 20342
LocalIp: 127.0.0.1
LocalPort: 1506
ClientCert: 

Running on Azure: https://app-tst.azurewebsites.net

Hello World - 4/27/2016 11:23:39 AM +00:00

Address:
**Scheme: http**
Host: app-tst.azurewebsites.net
PathBase: 
Path: /
Query: 

Connection:
RemoteIp: 127.0.0.1
RemotePort: 50115
LocalIp: 127.0.0.1
LocalPort: 3331
ClientCert: 

Headers:
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,fr;q=0.6,pt;q=0.4
Cookie: ARRAffinity=563f2aa954e138962d8a339b4323e825f5b3199e8a68887dd820180b7bbcd76c
Host: app-tst.azurewebsites.net
Max-Forwards: 10
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Upgrade-Insecure-Requests: 1
X-LiveUpgrade: 1
X-ARR-LOG-ID: 107216c4-474a-4f81-8e80-187bdc5feef9
DISGUISED-HOST: app-tst.azurewebsites.net
X-SITE-DEPLOYMENT-ID: app__6a69
X-Original-URL: /
X-Forwarded-For: 213.205.83.20:21003, 213.205.83.20:21003
X-ARR-SSL: 2048|256|C=US, S=Washington, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=Microsoft IT SSL SHA2|CN=*.azurewebsites.net
MS-ASPNETCORE-TOKEN: 4ddcc54e-59b2-414a-b4fc-c4e5d3973a57
X-Forwarded-Proto: https

Since i have a requireHttps attribute on all controllers, it keeps on redirecting because what apparently in Azure is reaching Kestrel is HTTP and not https.

The Browser then gets Failed to load resource: net::ERR_TOO_MANY_REDIRECTS

So this is the CURRENT and as of NOW issue and apparently the aspnetcore module has different behavior on Azure App vs Local IIS

Anything else i need to provide?

[Tratcher]

I see your issue now. You have two entries in X-Forwarded-For and only one in X-Forwarded-Proto. Our x-fowarded logic requires that there be the same number of entries in each of these headers.

You can override it by disabling x-forwarded-for like this:

            services.Configure<ForwardedHeadersOptions>(options =>
            {
              options.ForwardedHeaders = ForwardedHeaders.XForwardedProto
            });

@pan-wang can you investigate why there are two x-fowarded-for entries with the same value in Azure?

[LeandroPT]

@Tratcher

Your "hack" works perfectlly. I have made it using an appsettings switch, so as soon @pan-wang has news, please let me know.

[Eilon]

@Tratcher @muratg is there anything left for RC2 here?

[Tratcher]

I've asked @pan-wang to investigate why there are duplicate X-Forwarded-For headers, but that can wait. Moving to 1.0.0

[rustd]

Due to this all https scenarios are broken with Azure Web Apps.
All of the ASP.NET templates for Work & School Accounts are also broken as follows:

• Create a Web App with Work & School Account
• Publish to Azure Web Apps
• Browse to the site and login
• Login fails

[Tratcher]

Plan:

• Add an option to ForwardedHeadersMiddleware to disable the count check: Optionally disable the ForwardedHeaders count match check BasicMiddleware#37
• Have UseIISIntegration check if it's running in Azure and disable the count check by default.

In parallel we'll investigate with Azure Web Sites to see if they can improve their setting of these headers.

[Tratcher]

IsAzure check: https://github.com/aspnet/DataProtection/blob/8503e161d061fa230b00ba58d6801d7f906356ce/src/Microsoft.AspNetCore.DataProtection/Repositories/FileSystemXmlRepository.cs#L158-L162

[Tratcher]

Fixed in nightly dev builds.

[kevinchalet]

Have UseIISIntegration check if it's running in Azure and disable the count check by default.

Hum, why not just disabling symmetry by default for all environments?

The errors caused by the lack of symmetric are really hard to debug, specially since the log message associated with this error is not helpful at all and requires a high level of verbosity: Failed to parse forwarded [header].

[Tratcher]

We'll consider it if this comes up in most environments. For now we're using the most secure settings by default.