How to get request's remote client IP in Node.js?
What is the feature you are proposing?
How can i get the IP of the remote client?
I've seen https://hono.dev/docs/helpers/conninfo but there isn't anything for Node.js.
In Koa, its ctx.request.ip. code
May be useful:
- https://www.npmjs.com/package/request-ip
hi @movahhedi It depends on which deployment service you use.
Hello @EdamAme-x
Node.js, PM2, nginx/Apache.
Hi @movahhedi, You can pass the IP address as a header using nginx and a reverse proxy see here where this issue was discussed more
Isn't this feature good enough to be included in Hono [for Node]? Since it's there in Koa, It should be technically possible.
I don't think Node.js by itself is often used to build servers, what do you think? I think most would use a reverse proxy or a deployment service.
implement in Koa https://github.com/koajs/koa/blob/b89e19a27509c96d27af722f9951e0d72cb41eb5/lib/request.js#L455
If you implement it, you can add it to the getConninfo helper.
Hi @movahhedi, ConnInfo helper for Node.js has been released.
import { getConnInfo } from '@hono/node-server/conninfo'
getConnInfo doesn't seem super useful, koa's ctx.ip also resolves X-Forwarded-For which is most likely what you're looking for in a production system.
Indeed, though I'm not sure it's within the scope of ConnInfo Helper, I might need to support X-Forwarded-For.
@movahhedi I think this is what you might be looking for: https://hono.dev/docs/getting-started/nodejs#access-the-raw-node-js-apis
Update: Just used this for IP address while listing and it works:
import { type HttpBindings } from '@hono/node-server'; // import bindings
const app = new Hono<{ Bindings: HttpBindings }>(); // create hono instance with bindings
app.post('/endpoint', async (c) => {
const remoteAddress = c.env.incoming.socket.remoteAddress;
const blocked = remoteAddress === undefined ? true : !ipWhiteList.includes(remoteAddress);
// custom logic to handle when blocked to not
}
I agree @KaelWD that having X-Forwarded-For resolved would make it more useful for those using nodeJS for their server? If @yusukebe agrees with that, I would be happy to sponsor/bounty this work if anyone is interested!
@flipvh
Thank you for the comment. Regarding this issue, I'd like to know the opinions of the young developers. What do you think of this X-Forwarded-For matter? @nakasyou @EdamAme-x
If we use X-Forwarded-For to get IP address by default, the attack like this is able to cause.
await fetch('https://example.com/', {
'X-Forwarded-For': '1.1.1.1'
})
The following is a good example of why X-Forwarded-For is relevant:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomIPAddresses
It is important to note per @nakasyou comment that clients can set this header as part of their fetch request and naive code might be tricked. That said services like CloudFront have explicitly defined behaviours of how they handle this case and the actual client's request IP can still be determined (refer to the docs link).
Ultimately I don't think its hono's responsibility to address knowledge/skill issues regarding the use of any particular header or how infrastructure can play a role in modifying requests; what's relevant is that there are valid reasons for hono developers to be able to read any headers of any request including X-Forwarded-For.
X-Forwarded-For can be important when something such as an nginx reverse proxy, CDN like CloudFront, etc. is in front of the hono API and will set it and the developer needs to read it.
In these cases, the "conninfo" IP could be something irrelevant and useless like the internal network IP of a load balancer.
In various infrastructure/deployment scenarios a different custom header might be used to pass along the client's original request IP so it doesn't make sense to restrict to certain hard-coded headers.
Example use-cases where a developer may need this value are throttling / rate limiting and analytics.
Thanks @firxworx, makes sense. This leaves us with only a docs suggestion: perhaps mentioning the possibility of a custom GetIPAddr function could get more attention. But that is very much a nice-to-have I guess :D. We will write our own function for this.
Here's my library get-user-ip for getting IP addresses, which can be customized by specifying the second argument
Maybe this is a good option, or encapsulated as a middleware?
what's the "hono way" of doing this?