Include request IP address on event object

Support
1

Hey-o :wave:

I’m using Auth0 in conjunction with Netlify Functions. In an effort to prevent brute force attacks, Auth0 recommends sending along the end-user IP.

It doesn’t look like the end-user IP address is attached to the event object passed to the function. Is that possible within the platform?

I see that it’s likely possible with AWS Lambda.

Thanks!

2

I don’t think that we intend to share that, for GDPR liability reasons. We commit to in general not sharing PII from your visitors outside of our short-retention logging system that we use to debug. More details here: Netlify’s commitment to protect your data

3

Well, that is disappointing.

We need to collect IP address, and we issue a data collection and ethics notice before collection of data, and we manage sensitive data according to our policies. That is to say, managing sensitive data is our responsibility, not yours.

Why are functions on Netlify different from any other hosting scenario? If this were a cloud-hosted web app, Azure/AWS/etc… wouldn’t be responsible for filtering out IP addresses. In fact, as mentioned above, it’s part of the AWS Lambda API.

4

I can’t really speak to the full details of why we implemented things this way, but I can say that GDPR was already on our radar before we implemented the functions feature. While I do believe that you are a responsible consumer, I hope you can appreciate that out of our hundreds of thousands of customers, most are not that savvy and in today’s litigous society, we need to help the majority be responsible by not making it easy for even them to violate the GDPR themselves. While I am not a lawyer, it is my belief that it is still possible that we’d have to go to court with them, if they do, using our service in a “default” mode.

You are of course welcome to use other providers for your functions needs that enable IP gathering, along with your netlify site. I’d use our proxying feature (Redirects and rewrites | Netlify Docs) to keep this transparent, unless you are already accessing your dynamic code using something like XmlHTTPRequest in which case it may not be a win.

I have filed a feature request to make this adjustable, but I do not expect it to be implemented. I will follow up here as the conversation around it progresses, if any decisions (for or against) are made, or our implementation changes.

5

Guess what, I’m wrong, so you can be less disappointed @atruskie, and @estrattonbailey it seems like there is a solution for you too! There is no problem with you accessing/processing the IP that is already available (and @talves has a great code example that he will share with us) in the function environment.

Two main caveats:

  1. If you access this data, you DO take on the responsibility of creating your OWN DPA which it is your responsibility to communicate to your end users as to how YOU handle that data, once exported from our intentionally short-term storage (function logs do not last very long in our system).

  2. Around the data that Tony is going to share, note that we reserve the right to change the field names without notice, and you will NOT want to rely on X-Forwarded-For even today since that can reflect intermediaries such as cloudflare or other proxying situations (even some internal to our network), but instead one of the other fields that has that data.

1 Like
6

Here is a quick and simple debug handler function to help you easily see what the event and context values contain in the logs. In your case you should be able to get the IP through event.headers.client-ip.

my-debug-handler.js

exports.handler = function(event, context, callback) {
  console.log(`{\ncontext: ${JSON.stringify(context,null,2)},\nevent: ${JSON.stringify(event,null,2)}\n}`)
  callback(null, {
  statusCode: 200,
  body: `Your IP address ${event.headers['client-ip']}`
  });
}

Note: This is a method I would use to test event.body and event.queryStringParameters values when debugging functions.

7

Thanks for the response, that is good to know :slight_smile:

I did do something similar to what @talves suggested when debugging locally with Netlify CLI. However, in that case, I didn’t see client-ip listed in the available fields. After that, I tried to search, and the search led me here.

Perhaps client-ip should be listed in headers in Netlify CLI’s dev environment?

8

Oh great! Thanks for the quick response. I had only inspected the headers locally, my mistake.

I hear you on the privacy concerns. I think it would probably be a good addition to the docs, albeit along with a note about responsibility.

Thanks!

10

Perhaps client-ip should be listed in headers in Netlify CLI’s dev environment?

issue filed for this on netlify dev

4 Likes
12

And now fixed in latest merge on the ticket @swyx linked to

13

Hi, I thought I’d add some additional info to this thread because I ran into some issues regarding client-ip. Circumstances may have changed since the last posting so I thought this might help others.

While client-ip was showing up in my Lambda function, I was seeing an unusual IP address, 100.x.x.x. I guess it’s an internal range Netlify might be using.

In any case, get the visitor’s correct IP address by using the extension NF added to the headers: x-nf-client-connection-ip.

Update: just came across a related thread indicating this is indeed the new solution: Is the "Client-IP" header going to be supported long term?

1 Like