I want to do something like this in discourse:
Normally I would do it in an nginx.conf file. However with discourse, I don’t know what to do. Can someone help me?
I’ll write my solution I used earlier.
In the containers/app.yml
See the templates that’re inserted
Copy the name of the cloudflare.template.yml
Now edit the app.yml
Save it, now
./launcher app rebuild
Does this works with the set up where web sockets are used?
To be specific, my installation is running behind a nginx proxy as described here
is it possible to enable the cloudflare template?
Sorry but as far as I know its for cloudflare IPs. However, I have my own IP. And even if I would change this file for a little, I don’t know if my changes would be overwritten in future or not.
My use case is that I have a php file for login/sign-up using api calls and it is in one of my servers. Assuming that the public IP of that server is 220.127.116.11, all IPs inside discourse is reported to be also 18.104.22.168. And it would pass all limits very soon.
Not quite sure, but Google “nginx reverse proxy pass client ip”
I know about this part. I just don’t know how to implement it in discourse nginx. There is a template for cloudflare ips. but there is not a template for custom ips or any instructions, as far as I know.
It seems I got it fixed by adding another template named customip.template.yml and adding it to app.yml.
I organized the content of the template like the following
# Add list of custom ips
echo "22.214.171.124" > /tmp/custom-ips
# Make into nginx commands and escape for inclusion into sed append command
CONTENTS=$(</tmp/custom-ips sed 's/^/set_real_ip_from /' | sed 's/$/;/' | tr '\n' '\\' | sed 's/\\/\\n/g')
echo custom IPs:
echo $(echo | sed "/^/a $CONTENTS")
# Insert into discourse.conf
sed -i "/sendfile on;/a $CONTENTS\nreal_ip_header X-Forwarded-For;\nreal_ip_recursive on;" /etc/nginx/conf.d/discourse.conf
# Clean up
- exec: "/tmp/add-custom-ips"
- exec: "rm /tmp/add-custom-ips"
I don’t know to what extent my solution is correct and well organized. but it seems it just worked for me.
Looks good to me, you highlight the super important fact there that you can not just trust any IP address with that header, cause if you did, user IPs can be spoofed.
An alternative I have seen (that we use in haproxy) is setting the IP only if we see some top secret header that we have the CDN always send us.