in commit 89d7ff4 change extract last ip from x-forwarded-for, bud client ip is first, spec: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For. For me this broke my app.

Hi there

Something wired is happening and I can't get it what.
The case:
I'm making a request to a nodejs http-proxy server and when the first request is made from the client, I'm getting ::1 as ip.
When I'm making the second request I get ::ffff:127.0.0.1.
When I'm making a request without a proxy, I'm getting all the time ::ffff:127.0.0.1
Is there something that i should know?

Thanks

Internal ip's (like 192.168.0.1) is not useful in any way for server, so we often filter internal networks from headers.

I am using the below code within my node js application and when i try to run it locally the code inside app.use is not getting triggered and ip variable is blank

var connect = require('connect');
var http = require('http');
app.use(requestIp.mw())
var ip
app.use(function(req, res) {
    // by default, the ip address will be set on the `clientIp` attribute
     ip = req.clientIp;
     res.end(ip + '\n');
    console.log('ip is %s',ip)
   
});

Getting the Mac address in most of the cases, is this normal ?

for example : *****:fb90:d07f:fee4:0:b:fbfe:1b01

Will you just bump this to 1.0.0 please?

It appears that the API is production ready and I would like the security of knowing that until 2.0.0 I don't need to worry that the single API is going to break or disappear.

Thanks.

request-ip goes down a list of different methods of providing an IP address, and picks the first one that works. If the user of this library doesn't filter out unknown/unexpected headers, this is quite a dangerous way of determining the IP address. If X-Client-IP wasn't filtered by the user's web server, then an attacker could set the X-Client-IP header themselves and request-ip would happily accept it as the 'real' IP.

A more secure design would be for the user to configure request-ip with the headers and request keys they expect to get the IP from, and to only use them.

At the moment you will always get null from fastify unless one of the headers match. Fastify puts most of the data you are looking for in raw, so my current workaround is to do the following, which is not ideal, but seems to work:

requestIP.getClientIp(request) ||
requestIP.getClientIp(request.raw)

So should be a simple addition to allow for this.

Hello, I have an error when trying to install this package, please remove this line https://github.com/pbojinov/request-ip/blob/master/package.json#L57

So X-Forwarded-For header can be exploited with this library if we add XFF header in the request.
On Nginx, we can use the alternative X-Real-IP header for $remote_addr value.

Maybe we can add something like below?

app.use( clientIp.mw({ prioritize: ["x-real-ip",], }) );

This will push change header priority list from default
[ 'x-client-ip', 'x-forwarded-for', 'cf-connecting-ip', 'fastly-client-ip', 'true-client-ip', 'x-real-ip', 'x-cluster-client-ip', 'x-forwarded', 'forwarded-for', 'forwarded', 'x-appengine-user-ip', ];

to

[ 'x-real-ip', 'x-client-ip', 'x-forwarded-for', 'cf-connecting-ip', 'fastly-client-ip', 'true-client-ip', 'x-cluster-client-ip', 'x-forwarded', 'forwarded-for', 'forwarded', 'x-appengine-user-ip', ];

The current master branch appears to be a build behind itself — e.g., the lib/index.js file is not current with the src/index.js file. Specifically, the lookup for the DigitalOcean-specific way of including the client IP address that's present on line 82 of src/index.js:

https://github.com/NCI-CCR-OIT/request-ip/blob/d8215ca9147c2a20a8a3d0304c4d04531c415c20/src/index.js#L82

is missing in the lib/index.js file. I presume all that's needed is a new npm run build to catch it up...

Im using request-ip in my fastify application and after I updated to Fastify@4 Im getting following warning:

(node:71664) [FSTDEP005] FastifyDeprecation: You are accessing the deprecated "request.connection" property. 
Use "request.socket" instead.
    at Object.emit (xxxx/process-warning/index.js:52:13)
    at Request.get (xxxx/fastify/lib/request.js:211:17)
    at Object.getClientIp (xxxx/request-ip/lib/index.js:88:21)
    at resolveIp (xxxx/dist/middlewares/my-file.js:7:89)
    at Object.fastifyReqLogger [as req] (xxxxx/dist/main.js:62:69)
    at Pino.asJson (xxxx/pino/lib/tools.js:132:33)
    at Pino.write (xxxx/pino/lib/proto.js:205:28)
    at Pino.LOG [as info] (xxxx/pino/lib/tools.js:62:21)
    at Object.routeHandler [as handler] (xxxx/fastify/lib/route.js:470:19)
    at Router.callHandler (xxxx/find-my-way/index.js:398:14)"

It is a simple fix by modifying the following code snippet:

as the latest version of fastify suggests.

Can I open PR with that fix?

File: index.js
Line: 20
Invalid header - X-Forwarder-For
Need: X-Forwarded-For

Is there a problem?

I use it like this const ip = requestIp.getClientIp(req);

thanks

version 3.1.0 missing is.js in dist folder

This module works great untill installing nginix, I get IP 127.0.0.1. any idea ?

Hello. I'm working a Reactjs project. And in my understanding, this module reture IP on server, how to receive ip on client? Regards

This package is not giving correct IP address on Live app deployed on heroku. It always gives :ffff:127.0.0.1 this IP address

const requestIp = require('request-ip');

exports.ipMiddleware = (req, res, next) => {
  req.clientIp = requestIp.getClientIp(req);
  next();
};

I have the above code and even when I am outputting in the console.log the req.clientIp it is null. This is through firebase running locally via an emulator. Ideas on why that may be?

The request is sent from within an iframe in a website.

Hello

Google cloud functions forwards original IP in the header x-forwarded-for. It works perfectly with this library.

Google cloud doesn't provide an option to use a custom domain with google cloud function. To achieve that we need to use Firebase hosting.

So when a user makes a request, it first comes to firebase hosting and firebase rewrites the request to google cloud function.

This time x-forwarded-for header will have firebase hosting (CDN) IP and they will add original IP in a header called fastly-client-ip

Sample request header forwared by firebase hosting

Header { host: 'us-central1-xyz.cloudfunctions.net',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36',
  accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8',
  'accept-language': 'en-US,en;q=0.9',
  'cache-control': 'no-cache, no-store',
  'fastly-client': '1',
  'fastly-client-ip': '103.228.xxx.xxx', // Original IP
  'fastly-ff': 's48hDkrIORDrAz3sjuyh5gIWcInqIjSROZ47KAY+w/I=!MAA!cache-maa18320-MAA, s48hDkrIORDrAz3sjuyh5gIWcInqIjSROZ47KAY+w/I=!MAA!cache-maa18323-MAA',
  'fastly-orig-accept-encoding': 'gzip, deflate, br',
  'fastly-ssl': '1',
  'fastly-temp-xff': '103.228.xxx.xxx, 103.228.xx.xxx',
  'function-execution-id': '0hjs129juok9',
  pragma: 'no-cache',
  'upgrade-insecure-requests': '1',
  'x-appengine-api-ticket': '06df6279b81c6e08',
  'x-appengine-city': '?',
  'x-appengine-citylatlong': '0.000000,0.000000',
  'x-appengine-country': 'US',
  'x-appengine-https': 'on',
  'x-appengine-region': '?',
  'x-appengine-user-ip': '35.192.2.154',
  'x-cloud-trace-context': '44ad94ad1640fba12579d8ee8a393993/17096524669660557033;o=1',
  'x-forwarded-for': '35.192.2.154, 35.192.2.154',
  'x-forwarded-host': 'fun-api.xyz.com',
  'x-forwarded-proto': 'https',
  'x-forwarded-server': 'cache-maa18320-MAA',
  'x-forwarded-url': '/api/users/xxxx',
  'x-nginx-proxy': 'true',
  'x-real-ip': '157.52.84.23',
  'x-timer': 'S1533819437.997477,VS0',
  'x-varnish': '3227790704, 2976440830',
  'accept-encoding': 'gzip' }

https://support.cloudflare.com/hc/en-us/articles/200170986-How-does-Cloudflare-handle-HTTP-Request-headers-

First exception: CF-Connecting-IP

To provide the client (visitor) IP address for every request to the origin, Cloudflare adds the CF-Connecting-IP header.

"CF-Connecting-IP: A.B.C.D"

where A.B.C.D is the client's IP address, also known as the original visitor IP address.

and

Sixth Exception: True-Client-IP Enterprise Plan only

To provide the client (visitor) IP address for every request to the origin, Cloudflare adds the True-Client-IP header.

"True-Client-IP: A.B.C.D"

where A.B.C.D is the client's IP address, also known as the original visitor IP address. This request header is only available on our Enterprise plan.

If you're willing, I can submit a PR.

In Cloudflare, you have the option to enable a pseudo-IPv4 header for servers that don't fully support IPv6. If this feature is enabled, every request will have a "Cf-Pseudo-IPv4" header which contains an IPv4 address. It would be cool if you could add this as a last fallback that gets tried if every other header fails.
Here's an article on it: https://blog.cloudflare.com/eliminating-the-last-reasons-to-not-enable-ipv6/#introducingpseudoipv4

As more of us start adopting ES6/ES2015 in node, we should think about re-writing the library to fit the modern landscape.

Here's the Node.js ES2015 Support: http://node.green/

What are you thoughts on having an ES2015 version and a backwards compatible ES5 version compiled with babel?

On the NPM registry, it is mentioned that the latest version is 3.3.0 but in the request-ip Github Repo, in the release section, we see support only till 3.2.0, and the same under changelog, we see that 3.3.0 is mentioned in the unreleased section.

Can anyone emphasize whether it's released or not after v3.0.2, there were build issues with the package.

Jest didn't exist at the time when this library was created.

So I have an application living on server that is on the same VPN as the clients. No matter what I do to get the VPN Local IP of the client hitting the server, it always comes back as ::ffff:127.0.0.1. Any thoughts ?

I'm getting "::1" this as my ip address, is this an issue ?

Hi,
I'm getting proxy IP instead of client IP, when I have app proxied via CloudFlare. Cloudflare docs we shoud look in CF-Connecting-IP, because value of X-Forwarded-For is same as CF-Connecting-IP only if previous not set (in my example is set with proxy IP). Now I'm getting only proxy IP in X-Forwarded-For.

Example headers I get:

Host: <somehost>
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip
Accept-Language: en-US,en;q=0.5
Cdn-Loop: cloudflare
Cf-Connecting-Ip: <CLIENTIP>
Cf-Ipcountry: <someval>
Cf-Ray: <someval>
Cf-Request-Id: <someval>
Cf-Visitor: {"scheme":"https"}
Cookie: _ga=<someval>; __cfduid=<someval>
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 162.158.90.163
X-Forwarded-Host: <somehost>
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: <someval>
X-Real-Ip: 162.158.90.163

Switch to Typescript from the current ES6 implementation

I'm using the library to enable IP whitelisting for a Next.js app hosted on Vercel. This causes a build error:

Failed to compile.

../../node_modules/is_js/is.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Middleware middleware

Import trace for requested module:
../../node_modules/request-ip/dist/index.js
./middleware.ts

This is this module's only dependency, can this import be dropped in favour of lightweight equivalents?

Hello, I have a question, and my suggestion, maybe the owner should enable the Discussion feature in this repository for questions like this, thanks.

Current issue

• The value of the Forwarded header is actually a complex object and not a simple IP, cf. RFC-7239
• Example: for=123.34.567.89,for=192.0.2.43;by=[APIGW_IP];host=apiid.execute-api.us-east-1.amazonaws.com;proto=https
• Example 2: for=94.134.90.17;host=public-api.example.org;proto=https (from our app logs)

Proposed solution

• Write a function getClientIpFromForwarded similar to getClientIpFromXForwardedFor

Use Case

We are using AWS API Gateway with a private ALB (load balancer) and need the IP to use for getting the geo location. AWS API Gateway uses the Forwarded header for the client ip (see example 2). (And the ALB will set X-Forwarded-For with the private class-c IP from the ALB, but that's another issue)

I would also be open to contribute a PR with tests and the required changes. WDYT?

Sources

• https://tools.ietf.org/html/rfc7239
• https://medium.com/@lancers/amazon-api-gateway-explaining-http-proxy-in-http-api-3ea0afe6b03c#:~:text=Forwarded%20header,de%2Dfacto%2Dstandard

More info here:
https://www.mend.io/vulnerability-database/CVE-2020-26302

The way that IP addresses are inferred from X-Forwarded-For is unsafe/incorrect here. You cannot trust any IP addresses in the headers except for the ones added by your proxies.

The code for this section links to:
http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html#x-forwarded-for

At the bottom of that line it says:

If a request from a client already contains an X-Forwarded-For header, Elastic Load Balancing appends the IP address of the client at the end of the header value. In this case, the last IP address in the list is the IP address of the client. For example, the following header contains two IP addresses added by the client, which might not be trustworthy, plus the client IP address added by Elastic Load Balancing:

X-Forwarded-For: ip-address-1, ip-address-2, client-ip-address

The correct way to detect this is to start at the end of the header and work backwards based on how many proxies you know are between your app and the internet. This should be configured by the user, or default to the last IP. For example, if you are running with a single ELB proxy, then you need to take the last value (which is added by ELB), not the first in the list.

here's my header on an azure web app:
'x-forwarded-for': '187.65.xxx.xxx:61598',

when you call is.ip('187.65.xxx.xxx:61598'), it returns false.

would you accept a PR to fix this?

According to this documentation (x-forwarded-for), the order of ip addresses in the x-forwarded-for header is:

X-Forwarded-For: <client>, <proxy1>, <proxy2>

From your documentation, you have highlighted that you pick the last one which conflicts with where the client ip is