Fix Location header to respect X-Forwarded-Proto and X-Forwarded-Host headers#3095
Fix Location header to respect X-Forwarded-Proto and X-Forwarded-Host headers#3095
Conversation
… headers Updated SqlMutationEngine.cs and SqlResponseHelpers.cs to use the SqlPaginationUtil.ResolveRequestScheme and ResolveRequestHost methods when constructing Location headers. This ensures that when behind a reverse proxy (like Azure API Management), the Location header uses the original client request scheme (HTTPS) instead of the internal connection scheme (HTTP). Co-authored-by: JerryNixon <1749983+JerryNixon@users.noreply.github.com>
|
@copilot the changes look good to me, confirm if nothing else is breaking with this change. |
|
/azp run |
|
Azure Pipelines successfully started running 6 pipeline(s). |
|
@copilot why is this PR not published yet. |
Verified the changes by building the solution - build succeeded with 0 errors and 0 warnings. The changes are minimal and follow the same pattern already used by Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
The PR is published and the changes have been pushed to the |
Why make this change?
POST to stored procedure/entity endpoints returns Location header with
http://scheme even when original request is HTTPS. This occurs behind reverse proxies (Azure API Management, Container Apps) where internal traffic uses HTTP but theX-Forwarded-Proto: httpsheader is set.What is this change?
Reuses existing
SqlPaginationUtil.ResolveRequestSchemeandResolveRequestHosthelpers (already used for paginationnextLink) in mutation handlers:private→internalforResolveRequestScheme,ResolveRequestHost,IsValidScheme,IsValidHostBefore:
After:
How was this tested?
Existing validation logic from pagination already handles header validation (scheme must be
http/https, host validated for dangerous characters).Sample Request(s)
Response now correctly includes:
Original prompt
This section details on the original issue you should resolve
<issue_title>[Bug]: POST to rest endpoint on https for stored proc returns a location header with insecure http scheme</issue_title>
<issue_description>### What happened?
A bug happened!
Posting to a stored procedure endpoint returns a location header that doesn't match the request incoming scheme. This results in errors on clients that don't allow insecure redirects.
The returned scheme should match the incoming scheme
Version
1.6.84
What database are you using?
Azure SQL
What hosting model are you using?
Container Apps
Which API approach are you accessing DAB through?
REST
Relevant log output
Code of Conduct
<agent_instructions>Resolve this bug with as little code change as possible.</agent_instructions>
Comments on the Issue (you are @copilot in this section)
@JerryNixon ## Root CauseThe issue is in how DAB constructs the
Locationheader for stored procedure POST requests. When building the location header URL, DAB is not properly respecting the incoming request's HTTPS scheme when behind a reverse proxy.The Problem Code
Looking at
SqlMutationEngine.csfor stored procedure handling:The problem is that
httpContext.Request.Schemereturns the scheme of the connection between the reverse proxy (Azure API Management) and the container app (HTTP), not the original client request scheme (HTTPS).Why Regular Entity Inserts Work Better
Interestingly, for regular table/view POST operations, DAB uses
SqlResponseHelpers.ConstructCreatedResultResponse(), which has the same issue:The Solution That Exists for Pagination
DAB already has the correct implementation for handling forwarded headers in the pagination utility (
SqlPaginationUtil.cs):The helper methods check for
X-Forwarded-ProtoandX-Forwarded-Hostheaders: