Request.Scheme is not reliable and should not be used here for setting the Callback Url

[eat-sleep-code]

I have an application that requires https. When the authorization request goes to Microsoft for authentication, the redirect_url attribute shows up as &redirect_uri=http%3A%2F%2F. Note the http instead of https.

We believe we have tracked this to: https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication/AuthenticationHandler.cs#L118

Request.Scheme will incorrectly report 'http' even if originating URL is 'https'. I have confirmed this by placing @(Context.Request.Scheme) in the view of a page and loading that page under HTTPS.

Please either fix the Request.Scheme or provide a method of setting the callback path's request scheme.

I found two additional users who are having the same problem: https://social.msdn.microsoft.com/Forums/expression/en-US/833373e1-52ed-4d98-857a-ced4927a2dbb/azure-ad-authentication-for-core-web-app-uses-http-for-reply-url?forum=windowsazurewebsitespreview

[Tratcher]

Issues with Request.Scheme are usually environmental. See:
#757
#853

[eat-sleep-code]

We don't have a load-balancer in front of this server, but we do have a content filtering appliance. Apparently it is stripping the x-forwarded-proto header. The workaround you posted on #757 worked.

I am thinking that Request.Scheme should have a fallback within Request.Scheme that looks at the URL instead of just the header.

Otherwise the introduction of a new network appliance by a networking team could completely break an application and people would be left scratching their heads.

[Tratcher]

The scheme and full URL are not fields in HTTP requests. The request includes a Method, the Path & Query, the Version, and an open set of headers. On the server side the Request.Scheme is inferred from if the underlying connection used SSL/TLS or not. When you put an appliance in front of your server that terminates TLS connections and forwards you the requests over an un-encrypted connection your server does not know if the original connection was TLS or not. The standard workaround for this is for appliances to add an X-Forwarded-Proto header to indicate if the original connection was TLS. Failing that, if you know your server is always receiving requests over TLS you can manually set the scheme like this:

app.Use((context, next) =>
{
  context.Request.Scheme = "https";
  return next();
});

Note this affects far more than redirects, it also affects things like link generation, cookies, etc..

[andycmaj]

@Tratcher, I'm running into the same issue when running aspnet core in a docker container and terminating SSL at a load balancer.

Cookie authentication redirects don't work because AuthHandler always tries to redirect to http, since from the container's perspective, it's just serving up http.

Are you suggesting that the middleware/auth handler will respect the X-Forwarded-Proto header when generating redirects, or should i go with the manual Scheme setting technique?

EDIT: Ahhh just saw this: https://github.com/aspnet/BasicMiddleware/blob/dev/samples/HttpOverridesSample/Startup.cs#L13. looks like #757 is what i'm running into.

[h3smith]

@Tratcher

app.Use((context, next) =>
{
  context.Request.Scheme = "https";
  return next();
});

Seems to do the trick. We assume TLS by default, so we disable it with an environment variable if necessary. (Docker -> AWS ECS behind an AWS ELB)

Works fine now.

[Eilon]

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.