I am using WebAuthenticationDetails in my application.The method of WebAuthenticationDetails's getRemoteAddress() returns same IP address even if i login in application from different client machine.This may be due to proxy server.Can anybody help me to resolve this issue?
If your app is working behind a reverse proxy (for example nginx, Apache, etc.) then you'll always see IP of the reverse proxy machine in the WebAuthenticationDetails object. To solve this problem you can configure your reverse proxy in such a way that it will send client's IP address to your application server using a HTTP header. Then in your webapp get clinet's IP from this header.
Related
I am using my own squid proxy server,when I check my ip address on whatismyip.com, it show the ip address of my proxy server.
But, when I check on speedtest.net, I found that they can track my client IP.
Is there any ways to prevent my real IP being detected ???
Your IP is provided by your ISP (internet service provider) and speedtest.net picks up your gateway/router.
Thus "trying" to hide behind a proxy would not have any effect.
Say I have a list of proxies - I pull out of one of these proxies. It's nothing but ip and port. From a programming level, you need to know the protocol to use such as socks5, socks5h, http, https... etc etc. Is there a way to retrieve what kind of protocol a proxy uses from the information given?
If you are using Node.js you can try check-proxy library, though it does much more than just checking protocol.
Your proxy server identify the port number for example 6080,9180,etc so you can easily identify the proxy server.
Your id address also private or public you can use 'proxy server ip address' that automatically create a virtual proxy network.
Example: Your private ip address is 172.16.10.158 you can use proxy server, your ip address will be 136.56.89.210. You can use public ip ex 125.124.85.69 change in to 179.68.36.49.
I'm trying to use Fiddler to capture traffic that comes to my machine on its external ip address, and redirect it to the loopback interface without affecting the host header.
I have added the following to the OnBeforeRequest method:
if (oSession.HostnameIs("MyMachineName")){
oSession.bypassGateway = true;
oSession["x-overrideHost"] = "localhost";
}
This works fine for http traffic: I do indeed see a request to http://MyMachineName hit the loopback adaptor with its host header intact.
However, when intercepting https traffic I get the following in the response raw view:
fiddler.network.https> HTTPS handshake to auth.time-wise.net failed. System.IO.IOException The handshake failed due to an unexpected packet format.
I have Fiddler configured to capture and decrypt https traffic.
Does anyone know why this problem occurs and how it can be remedied?
Edit: in response to Eric's request for more information
Fiddler is running as a proxy (i.e. as standard), listening on port 8888.
The clients are (currently) web browsers on the same machine, and so are automatically using the Fiddler proxy, as they've picked up the change in default proxy.
You've left out some important details (e.g. what port is Fiddler running on, and how did you configure the remote client to send its traffic to Fiddler?)
Having said that, you will probably want to change your use of x-overrideHost to x-overrideHostname such that the port number of the traffic being retargeted is preserved.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.
http://ipfuck.paulds.fr/
We've been recently getting hammered by this Firefox plug-in. It sends a fake IP in the headers so when our nginx web server picks up the IP it is a fake one.
Is there any way to get a real IP address or block out requests that have this plug-in installed?
There is actually no client IP entries in any HTTP Headers. There are only some un-official proxy headers which are added to a request, so that a proxy server can tell you the real ip of the connecting client (since the tcp socket will only reveal the IP address of the proxy server).
The plugin you linked to adds those proxy headers, to "fake" a proxy request, by adding a X-Real-IP: 1.2.3.4 or X-Forwarded-For: 1.2.3.4 header to the request. But no one forces you to use that IP address (which can be fake, like the 1.2.3.4 example here), you can always use the IP address of the socket that initiated the connection - which will be the client's real IP address if he uses the mentioned plugin.
Within the location section of your nginx configuration, you get the socket IP address through the $remote_addr variable. To retrieve the "fake" IP address, you can use $http_x_forwarded_for or $http_x_real_ip variable.
If you are using any application/cgi backend, you usually can examine the full headers and the socket IP address (i.e. in PHP you should check $_REQUEST and $_HEADERS variables)