Make HttpsRedirectionMiddleware throw if there are multiple ports #29166
Conversation
Tratcher
added
the
breaking-change
ghost
added
the
|
Should we bring this to API review? |
It's not an API change. I don't think we have a process for reviewing these types of changes beyond code review. Note I did review it with Barry in advance. |
|
Okay, probably an announcement is a good idea. Also, does this break any default scenarios on app service (windows or linux)? |
I'll do that next.
It shouldn't, they either terminate TLS at the proxy or only have one https port. I've only seen self-hosters get into this situation with multiple https ports. |
|
Yeah, I think the scenario where this breaks on app services is when there are not HTTPS port. |
|
It will continue to default to off when there are no https ports. Doesn't app service enable https by default now? |
|
I don't think so, IIRC the main concern was app service for linux. |
|
App service for linux terminates TLS at the proxy. We had lots of issues there with the forwarders, as well as getting the port. We got redirection working by specifying the proxy https port in the config (container?). |
|
Announced: aspnet/Announcements#448 |
|
Hi @Tratcher. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
amcasey
added
the
area-middleware
Fixes #27951
When the HttpsRedirectionMiddleware isn't explicitly configured it will search IServerAddresses to figure out what https port it should redirect to. This doesn't work if there are A) no https address or, B) multiple https addresses with different ports.
When this feature was first designed we decided that case A should no-op to avoid breaking scenarios like development, deployment behind proxies, etc.. Case B was treated the same way, but I don't think we explored that scenario enough.
When IServerAddresses reports multiple distinct https ports it's clear that the site is using https and that the middleware should be active to protect sensitive data, but it's ambiguous which port it should redirect to. The customer feedback for this scenario is that they'd rather fail the request then let it succeed silently and risk data exposure.
#21291 is for follow-up work to let the developer resolve the port ambiguity, but this error would still be needed when that advanced config is not provided.