Mvc: Too many redirect when using RequireHttpsAttribute

[endink]

if a use RequireHttps in a controller class:

[RequireHttps(Order = int.MinValue)]
[Authorize]
[Route("[action]")]
public class XXXController

if i remove RequireHttpsAttribute, it will work well.

in Microsoft Eage will always loading, in chrome show "ERR_TOO_MANY_REDIRECTS".

[imranbaloch]

Are you running your app a behind Load Balancer e.g, Amazon, Azure F5, etc. Normally, the traffic between load-balancer and your server not use https. You can check X-Forward-Proto header http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/x-forwarded-headers.html

You can override RequireHttpsAttribute to check X-Forwarded-Proto header(hopefully your load balancer set the X-Forwarded-Proto header correctly). https://github.com/aspnet/Mvc/blob/3c2bdfd368f1b0ed81e92f9287f43a58be06e6e0/src/Microsoft.AspNetCore.Mvc.Core/RequireHttpsAttribute.cs

[endink]

@imranbaloch
yes i will deploy my application on Azure VM ( windows iis) finally, but this issues appeared when i deploy it on my local PC (windows 10) IIS for testing.

BTW, does X-Forwarded-Proto support for Azure ( virtural machine) ?

thanks!

[imranbaloch]

Oh you are running localhost. Check this how to configure self signed cert http://mobilemancer.com/2016/02/20/asp-net-5core-iis-express-and-ssl/

[endink]

@imranbaloch
I use OpenSSL to generate self signed cert , and openning "https://locahost/Index" in browser is Ok, issue only appeared the controller with RequireHttpsAttribute applied.

[imranbaloch]

If you can debug the source and check filterContext.HttpContext.Request.IsHttps == true https://github.com/aspnet/Mvc/blob/6.0.0-rc1/src/Microsoft.AspNet.Mvc.Core/RequireHttpsAttribute.cs#L22

[endink]

@imranbaloch
I can copy code to a custom filter attribute for debug, but I can't use ssl in development environment, because iisexpress wasn't supported in RC2(1.0-rc2-20100)

[endink]

@imranbaloch
BTW, azure use X-ARR-SSL header for check？

[imranbaloch]

I haven't used this Azure Load Balancer but look like you are correct https://tomasz.janczuk.org/2013/12/secure-by-default-with-ssl-in-windows.html

[Eilon]

@sebastienros can you have a look?

[sebastienros]

202

[Eilon]

cc @Tratcher @BrennanConroy - are you guys looking at the same issue possibly in the IISIntegration repo?

[Eilon]

@JunTaoLuo I wonder if maybe this is what you were running into as well with Hubbup?

[sebastienros]

Can you try to remove the Order from the RequireHttps attribute, I wonder if there could be a conflict between the Authorize redirection and the https one.

[sebastienros]

Also, can you confirm that you are running https on 443? As you are not setting it in the code and I don't see your configuration, the default behavior is to drop the port during the redirection, which implies 443.
Would be nice to see a trace of the redirects, either with Fiddler or Chrome extensions.

Thanks

[Tratcher]

I don't think this is related to https://github.com/aspnet/IISIntegration/issues/140#issuecomment-215135928, that's azure specific.

[Eilon]

@Tratcher ah yes good point.

[sebastienros]

I can't repro the issue, I have tried adding the attribute with default [RequireHttps(Order=0)], and your example [RequireHttps(Order=int.MinValue)] and also with the [Authorize] attribute.
I am doing it locally with IISExpress on RC2 official, and SSL works correctly. I am correctly redirected to the authentication page under SSL, and when authenticated to the actual page. Works also when logging off and it stays on https.

It would be great if you could provide us with the redirection loop details to understand where the issue occurs.
Could you also confirm it repros for you with the RC2 release?

[sebastienros]

I tried this scenario and it worked for me. There is no such specific login path for https.
If you could answer the previous questions I posted that could help understanding what happens in your case. Thanks.

[endink]

think it because Authorize attribute auto redirect to LOgin action (http) and Login auto redirect to https . Is there a option to specific https for login path?

[endink]

ok I will post loop log when I at office today, please wait , sorry. Now I am not in office

[kichalla]

I am also unable to repro this issue with RC2 bits + local IIS. The filter that gets created when Authorize attribute is used has an Order of 0 and since you specifically set the order of RequireHttpsAttribute to min value, the RequireHttpsAttribute would be the first one to execute.

Would it be possible for you to give us a repro sample? We are eager to see if there is any real issue here to be fixed for the next major 1.0 release.

[endink]

when i upgrade to latest rc2 version , the issue was disappeared, maybe the issue only exsit in RC2-20100

[Eilon]

@sebastienros if you are satisfied with this, please close.

[Eilon]

Remove 3-Done, adding no repro (because we didn't fix anything).

[mkarlsson]

I have this problem since upgrading to RC2, but only when publishing to Azure. Vijay Ramakrishnan have been helping me problem solving the problem but only removing the Require attribute solved the issue. I have a customer that need help upgrading in the coming weeks so if anyone knows a workaround to get RequireHttps attribute to work on RC2(worked for months on beta8 and RC1) please let me know.

[Tratcher]

@mkarlsson see https://github.com/aspnet/IISIntegration/issues/140#issuecomment-215135928 for Azure https issues.

[mkarlsson]

@Tratcher Great, that solved my issue.

[AhmedMozaly]

For me, it is really weird behavior need to be changed
assuming that hosting environment is load-balancer-free is not the right assumption, ASP.NET MVC should be cloud-ready by default

I should not spend much time before figuring out that ASP.NET MVC can't see the giant thing in front of it, so called load-balancer

PLEASE RE-OPEN THIS ISSUE

@Eilon @sebastienros

[Eilon]

@Tratcher @sebastienros thoughts?

[sebastienros]

This is new valuable information that it's related to request forwarding, that could explain why we couldn't repro. I need to look at how we should handle the scenario, will check with Chris as he probably already knows.

[sebastienros]

@AhmedMozaly did you see this comment https://github.com/aspnet/IISIntegration/issues/140#issuecomment-215135928 ?
Looks like it might solve the issue you are seeing.

[sebastienros]

Tried again on Azure App Services, and it worked without any issues for me.

[plioi]

Rather than discard the built-in attribute in favor of one that peeks at the forwarding headers, leverage the UseForwardedHeaders method so that HttpContext.Request will have accurate properties in the first place. It took a lot of digging to even know this was an option:

app.UseForwardedHeaders(new ForwardedHeadersOptions {
    RequireHeaderSymmetry = false,
    ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor
});

So, this might not really count as a bug.