In the admin screen for users we can see their last visited and registered IP addresses. In line with my company’s approach to privacy, we don’t want to record these but I can’t see a setting to switch it off. Is there something I’m missing, or would we have to fork Discourse? Or perhaps a plugin could override the code?
Any help is appreciated.
There are a number of anti-abuse measures that rely on having knowledge of the client IP address in order to function. Also, the client IP is logged in a number of places, including at least two different log files (nginx access log and rails log), so you’ll need to modify some pretty deep config in order to get rid of those, too. And yes, I’d say you’re likely going to need to fork to eradicate all those.
Thank you for the quick answer Matt. We’ve already worked on the log files to stop IP addresses being recorded there. Looks like we’ll have to dig deeper for the remainder to not be logged. Seems to be beyond what a plugin can achieve.
You could likely setup a nginx proxy in front of Discourse and have it pass in 0.0.0.0 for all IP addresses.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Thanks very much @cpradio, that sounds like a good idea. I’ll suggest it to our developers.
Then you will need to turn off rate limiting, because everything will look like a DDOS.
Good thinking @Falco. I’ll change the rate settings if we go down that route.
Maybe it would be easier to let the IPs be recorded and then periodically run a query that changes them to random private ip addresses, say daily?
Thanks @codinghorror. Ideally we don’t want the IPs touching our database/logs but that’s something to consider.
Another idea is to intercept the IP lookup call and replace it with a modified, random version of the “real” IP (so every request doesn’t appear to come from the same IP, or a totally random IP). That would probably be safest in my opinion.
@codinghorror That sounds like a really good compromise, avoiding having to turn off rate limiting. We’ll probably go with this, barring difficulties. Thanks for all the help to find a solution.
Hey @tagawa, I’m in a similar situation and was wondering if you’ve found a good solution to this?
Can someone provide a solution for this, pls? I am not familiar with the internals of Discourse, so a step-by-step instruction is much appreciated. Thx!
All of the solutions here work outside of Discourse, changing how nginx, the http software used, understands the IP address (and Discourse then will trust the value received from nginx). None of the solutions here look “fully baked”. So the instructions you want don’t exist.
Thanks for clarification.
So in fact the answer to privacy concerns people have with Discourse is “Not our problem!”, right? That is my interpretation of the answers given here.
Privacy of the never log IP addresses sort is a real outlier. Most admins want to have IP addresses for some amount of time for identifying rogue behavior. For example, password change requests are limited to a certain number per hour per account per IP address (pretty sure the limit there is 6). Take away IP and that doesn’t work.
So “Not our problem!” is a very unfair characterization of your request.
Sorry, i don’t meant to be rude. It’s kind of annoying to be left with unclear hints and not to know how to proceed.
The best info i’ve found on nginx and masking ip address is this blog post: https://www.nginx.com/blog/data-masking-user-privacy-nginscript/
Here begins my problem: how do i implement this for Discourse? And not to lose the changes made with the next rebuild? I have installed Discourse via Docker which is the only supported way if i remember correctly.
That solution requires the commercial version of nginx, not the open source one. The simple solution to use that without interfering with the Docker install is to get that version of nginx as a proxy for your Discourse and to use the IP address rewriter to create the X-Forwarded-For header.