Proxy requests that return a 403 error - issue with sending headers

[Friscia, Michael]

Even though it seems wrong, I’m still going to try adding “always” to that just to test. But I agree that it is not likely going to make a difference since my goal is to send a value upstream and not apply it to the return from upstream.

To answer the other, if I inspect the page that comes back with the 403 error, none of the headers I listed below appear. But if I inspect a page that comes back as 200, then the headers are present.

The order of operation is this
User make request to Nginx
-> Nginx makes proxy request to our URL rewrite proxy
-> the url rewrite proxy makes a request to the web application

The goal is for the client IP to make it to the web application. It is clear that nginx needs to pass the header to the second proxy which will then pass it along to the web app. It seems that the proxy_set_header is what I need to add but it does not seem to be happening.

Is there any explanation why the proxy_set_header may not actually get set?

___________________________________________
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 – office
(203) 931-5381 – mobile

http://web.yale.edu


From: nginx <nginx-bounces at nginx.org> on behalf of Jason Whittington <Jason.Whittington at equifax.com>
Reply-To: "nginx at nginx.org" <nginx at nginx.org>
Date: Thursday, March 15, 2018 at 4:40 PM
To: "nginx at nginx.org" <nginx at nginx.org>
Subject: RE: Proxy requests that return a 403 error - issue with sending headers

add_header is used to add a header to a response.  It’s not entirely clear to me that that’s what you want to do.  But if so, add_header won’t run for non-200 return values by default.  If you want to propagate the header for error conditions add the “always” option:

add_header X-Origin-Forwarded-For $remote_addr always;

But this still feels weird to me so maybe I am missing something. Why would you want to add that header to the response (other than for debugging)?   The equivalent proxy_set_header (line 4 in your example) seems like all you should need to me.

Jason

From: nginx [mailto:nginx-bounces at nginx.org] On Behalf Of Friscia, Michael
Sent: Thursday, March 15, 2018 3:04 PM
To: nginx at nginx.org
Subject: [IE] Proxy requests that return a 403 error - issue with sending headers

I hope I can explain this well enough to understand what I’m doing wrong.

The problem I am trying to solve is that I am making proxy requests to a site that has IP restrictions. Nginx is making a request to another Proxy URL rewrite server we use which then makes the request to the web application. So what happens without any work is that the second proxy server is making the request with the Nginx server IP address. So we made some changes to headers in Nginx to pass the client IP and then it would forward through the second proxy, make it to the web app and process the IP restriction.

I have a block in my global settings that offers these header additions.

add_header X-Origin-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Server $hostname;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Origin-Forwarded-For $remote_addr;
proxy_set_header Accept-Encoding identity;

It’s really the X-Origin… that I care about. But what seems to be happening is that for any normal request, the client IP address is being passed to the web app but when I make the request for a page that returns the 403 error because of the IP restriction, none of the headers above are being applied to the request. So the web app is never getting passed my custom headers.

My question is if there is some sort of setting I am missing and I ask that making an assumption that the problem is that Nginx is making a request without sending headers, getting the 403 error and then all processing stops and I just get an access denied page.

Any thoughts on how to handle this problem would be appreciated. I’ve tried numerous things and the root of the problem seems to be that Nginx is not making the full request. My next assumption is that this global configuration is to blame by having “error” in the list
proxy_cache_use_stale error timeout updating invalid_header http_500 http_502 http_503 http_504;

Thanks,
-mike

___________________________________________
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu<http://web.yale.edu/>

This message contains proprietary information from Equifax which may be confidential. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmaster at equifax.com. Equifax® is a registered trademark of Equifax Inc. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180315/f925e5fe/attachment-0001.html>