Stop Discourse leaking its Host IP adress when preloading links/ressources

[Yogurt]

I refer to this post here: Discourse Link previews through a proxy server?

First of all, sorry to resurrect this almost 10 year old post, but I seriously can’t believe this doesn’t bother anyone else?

I have now managed to hide my host server and its IP address behind cloudflare and, after hours of searching, I have managed to only allow incoming network traffic from cloudflare so that port scanners cannot accidentally discover the forum under the IP address. Safety is simply very important to me. Mail server is external, almost everything is protected - but it’s a joke that someone just has to insert a bait image in the post and Discourse downloads it directly to embed it or something similar. I couldn’t find anything that disables this anywhere. Even these oneboxes, which are supposed to be the previews - even setting these to 0 does nothing - the ip logging pixel was immediately embedded and could reveal the host’s IP to attackers - so cloudflare’s protection is absolutely useless in this case. Either you protect your services properly or not at all - what use is cloudflare to us if the attacker doesn’t need 5 minutes to register, post a picture and thus find out the real IP of the host?

I’ve been trying for hours today using AI, tor and torsocks - but it never really worked. The rebuilding usually crashes as soon as I dare to change something in the env settings. If anyone has somehow managed to do this, I’m almost begging them to please share it with us. Most of the time the rebuild fails because access to Github doesn’t work, as Github probably prohibits Tor traffic.

And all of this wouldn’t have to be the case if you could simply deactivate discourse from loading the links in advance.

I’m really desperate.

[merefield (Robert)]

Might this help?

"Onebox Assistant", crawl for those previews reliably!

What it does [A woman in a straw hat and khaki shirt is using binoculars to observe something in a mountainous area, with a clipboard nearby. (Captioned by AI)] Turns this kind of result: [image] (where your server has failed to bring back the page source so cannot extract the required tags to build the onebox) Into this!: [image] It simply provides an alternative path for onebox to get its page source with which to look for meta-data when the target server refuses your connection. It …

It wasn’t built for exactly this (main goal was to improve reliability) but might be part of a solution as it’s essentially using a proxy service.

[Yogurt]

thanks! I added your plugin and rebuild discourse- after that I thought, that if I check the first two checkboxes, it will enforce to use a proxy- nevermind if one is set up or not- but it doesn’t matter if I put infos of the proxy or if the values were empty and only the two checkboxes were activated- it still loads the tracking pixel with the VPS IP adr.

I’ll try now to to configure complete docker or only the discourse image to use proxy, maybe it will work with a usual proxy provider and won’t fail in rebuilding like with tor

[merefield (Robert)]

ah shame. plugin route is still the right way to go, regardless of the solution as it makes maintenance a lot easier

[RGJ (Richard - Communiteq)]

You can simply set up something like Tinyproxy on a separate host and configure environment variables to use that. Make sure to disable IP header forwarding on Tinyproxy and it might be helpful to exclude Github to ease theme installation as well.

@Yogurt

Most of the time the rebuild fails because access to Github doesn’t work, as Github probably prohibits Tor traffic.

You should be using such a mechanism when Discourse runs, not when it is being built.