I am trying to get the client ip at the server Y in the following scenario,
client requests server X which forwards the request to server Y.
And the return flow is Y->X->client
'REMOTE_ADDR' in the http header(actually i get it from request.environ['REMOTE_ADDR']) has the ip of server X. From where can i get the ip of the client at server Y ?
UPDATE:
X has a public ip. Y is in a private network and is inaccessible outside. Now i am using a client in the same private network and i request X via the public network.
I just want to know if the header already has what i need without manipulating the header at X to include ip of client.
If your application is behind a proxy then the remote address of the request will appear to your application to be from the proxy, not the actual client.
There is no provision in the http spec to pass on the 'real' address but the de-facto standard for doing this is by having your proxy set an X-Forwarded-For header
Werkzeug provides a fixer to help with this, and there's an example detailed in the Flask docs, request.remote_addr should then be what you expect
Despite your claims, X is basically a proxy, since it makes its own request to Y, based on a request the user makes. So it's perfectly valid that REMOTE_ADDR is the one of X.
You will have to add a custom header to X's requests, like X-Original-User-IP to make the user's IP available to Y. You can use ProxyFix for this if you want, it will rewrite X-Forwarded-For to REMOTE_ADDR
You should make sure Y is only available to X and cannot be accessed directly. Otherwise one could spoof his IP address simply by sending that custom header.
Related
I'm fiddling a bit with Azure API Management Gateway to see if it would fit our purpose.
It was quite simple to add an API from our ERP application (Saas app with IP whitelisting our Office locations) and I'm able to call it from within our office.
However, when I call the api from any other location, I get the message from the ERP that the IP is blocked.
I'm currently on a Development tier and (should) have a static IP assigned let's say
VIP public: 20.82.86.xxx
What I've done so far:
added a inboud policy, stripping the x-forwarded-for header, tried both API level and operation level
<inbound>
<base />
<set-header name="X-Forwarded-For" exists-action="delete" />
What I've tested/noticed so far:
When I test the call from within APIM, the IP is blocked. I can see that the header is stripped on inbound
set-header (0.008 ms)
"Header X-Forwarded-For was removed."
I see that APIM is adding a x-forwarded-for header in backend, seems with the IP of the frontend/APIM website
{"name": "X-Forwarded-For","value": "13.91.254.xxx"}
The response I get back is that the ip from my device (84.105.xxx.xxx) is blocked by the ERP
I don't understand why the originating IP is the local IP from my device/location instead of the API Gateway.
Azure API Managemnent gateway seems to be very useful for our purpose and it's not that difficult the work with. However it's important that I can call it from other locations than our office.
Any ideas?
I tested setting an explicit value for the X-Forwarded-For header like this in the inbound policy:
<set-header name="X-Forwarded-For" exists-action="override">
<value>xx.xx.xx.xx</value>
</set-header>
Then the resulting header in the backend request was:
X-Forwarded-For: xx.xx.xx.xx,yy.yy.yy.yy
This might fool your backend to think that xx.xx.xx.xx is your client IP, when it is really yy.yy.yy.yy.
If you have added any such header exclusively before forwarding the request to the backend via policy, it can be removed via policy.
But the X-Forwarded-For header being added by the APIM gateway by default cannot be eliminated since this is by design and is required by the service to accurately forward the request to the backend API.
https://www.geeksforgeeks.org/http-headers-x-forwarded-for/
This article says:
With these added headers, Cloudflare passes on all HTTP headers as is
from the client to the origin.
However, there doesn't appear to be a standard way to get the Host from the original request.
Is there a way to do this, either via standard options or enterprise option?
I want to do some conditional Configuration in Apache based on one particular HTTP request header.
For eg.,
Enable HTTP Digest Authentication for a set of Client IP Address and enable HTTP Basic Authentication for another set of Client IP Address.
For dynamically changing the configuration I am using .htaccess but i am not able to find a way to read the Client IP Address in the Configuration (.htaccess) and apply condition based on the IP Address.
I tried using mod header but i couldn't figure out the way. Please provide me some direction in this regards
Would using the tags fix your problem ?
https://blogs.apache.org/httpd/entry/new_in_httpd_2_4
I need to redirect all requests on port 80 of an application server to a web server. I'm trying to avoid the need to install IIS and instead use WCF to do the job.
It looks like an operation such as the one below is suitable but one problem I've got is if a URL of the form http://mydomain.com/ is used then WCF will present a page about metadata.
[OperationContract, WebGet(UriTemplate = "*")]
RedirectToWebServer();
Does anybody know of a way to get WCF behaving the same as IIS in redirect mode?
This just seems like the wrong tool for the job. If you really don't want to use one of the many web servers that could do this with a couple minutes of setup time (IIS, Apache, Lighttpd), you could just make a simple HTTP socket server.
Listen on port 80. As soon as you get two newlines in a row, send back the response:
HTTP/1.1 301 Moved Permanently
Location: http://myothersite.com/whatever
(I'm almost certain that's the minimum you need). If you want to be really fancy and follow HTTP specs, match HTTP/1.1 or HTTP/1.0 based on what the request has.. but for a quick and dirty redirect, that's all you need.
That said, again, I'd say go grab another web server and set up a redirect using it. There are many lightweight HTTP servers that will work.
Does anyone knows how to tell Apache, in reverse proxy mode, to intercept or trap 302 (or 30x) responses from backend server and redirect internally without sending 30x response back to client?
Ultimately, the backend server the response is redirected to would not be accessible from the outside (or not listed in Apache conf).
My situation:
I have web_server_A and web_server_B listening on port 6666 and 7777. These ports are not accessible from outside, but are accessible from the inside.
I can eventually change the behavior of web_server_A, but not the one of web_server_B.
Apache is listening on ports 80/443, accessible from the outside and is acting as a reverse proxy sending requests addressed to web_server_{A,B}.example.com to web_server_{A,B}
The client asks Apache for web_server_A.example.com/foo. Apache proxies the request to web_server_A which makes some stuff and then sends back to Apache a HTTP/302 response pointing on web_server_B.example.com/bar/secret_token. Apache sends back the 302 response to the client which then sends Apache an HTTP request for web_server_B.example.com/bar/secret_token. Apache proxies the request to web_server_B, which replies something (usually it sends back some big file).
My problem:
I don't want the client to know about the url web_server_B.example.com/bar/secret_token, and ultimately I don't want web_server_B to be accessible from outside.
web_server_A could make the request to web_server_B and then send back the answer from web_server_B without issuing a 302 reply. But, the answer from web_server_B might take some time to come, might be quite big, and web_server_A should not spend too much time on any request (it has no ability for handling big files).
So I thought about a "302 trapper" feature that would be nice if existing, but so far haven't fund anything on the web on how to do that. Any idea?
As a reverse proxy, Apache won't be able to "block replies." It's not a censor.
You could write something like this yourself, though.
using ProxyPassReverse directive, web_server_A will modify Location header sent by web_server_B, so the client won't know about him.
to trap redirect from upstream server you can also edit Location header. For instance "Header unset Location" will show apache default 30X error page