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: https://www.netlify.com/gdpr/

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.

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 (https://www.netlify.com/docs/redirects/#proxying) 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.

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:

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).

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.

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.

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?