Use X-Forwarded-For header as ip if set

[LostKobrakai]

Using nginx in front of phoenix will result in logs all coming from the same http.remote_addr. It would be nice if this ip could also be supplied by an X-Forwarded-For header set by nginx.

[DavidAntaramian]

We source the http.remote_addr from conn.remote_id. I was under the false impression that Plug would appropriately reassign that field based on headers. It does not do that; instead it expects a chained plug to do that instead.

We may consider adding support for this to the library, but an immediate solution would be to use a secondary package intended for this purpose. At this time, it seems like remote_ip would be an appropriate solution.

[LostKobrakai]

Another thing related to IPs would be an option anonymize the IP in the context plug. Most tools just seem to strip the last part of the ip.

[DavidAntaramian]

Would it be preferable to just have it removed completely? I'm thinking about this from a service standpoint. If we only send part of the IP, that's not useful for reading or querying the logs, so it ends up being extra data that will never be useful. Meanwhile, not sending the IP at all frees up (very little) space but also means that potentially identifiable data is never sent to a third-party (Timber).

Also, depending on the IP block, only removing the last part of the IP doesn't result in anonymity.

[LostKobrakai]

German data security laws are a pain, but basically you could still run things like geo location on a trimmed ip, but it's no longer identifing the user close enough so you're not violating the law, while it's still a gray area for not trimming ips. Maybe the plug could just allow for a mfa option, so people can implement their own trimming.

[zacksiri]

I used the remote_ip hex and it all worked out.