Client IP is sent to downstream with Cache Purge request, instead of upstream pagespeed ip. #1068
Comments
Are there any |
Yes, i am using those because i needed my upstream to see the IP address of the client. without those the upstream saw 127.0.0.1:port. My config:
|
Thanks for the configuration, that should help reproducing. I suspect that the code that executes the purge requests copies over the incoming |
I was able to confirm the purge requests copying over |
Thanks for all your help Otto, I really appreciate it. |
In general you do want the purge request to copy over all the headers from the client request. If you have geocoding dependent content and so have set up a region-specific cache key that's dependent on the client IP, then if pagespeed didn't set This is causing you a problem because to get purging to work you needed to open up your purge handler to the whole internet. I agree that's bad and not how it should be configured. Can you add a check that |
It's actually not that unsafe (i think). Because on my main SSL block i drop all traffic to /purge:
And the upstream only listens to localhost, so effectively ip filtering purge requests to only come from the server itself. |
With Downstream Caching + Varnish + Nginx as SSL terminator, there is no way to tell whether PURGE request is originating from localhost or not. Only for the simple fact that all the headers are copied by pagespeed's request - it looks like an external request to Varnish. |
I have nginx as a downstream caching proxy. When pagespeed emits a cache purge to the downstream, the original client IP is sent with it. Example from my logs:
172.218.???.??? - - [10/Dec/2015:18:38:51 -0500] "GET /purge/storage-auctions/affordable-mini-storage/unit-120 HTTP/1.1" 200 330 "https://dev.bid13.c
om/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36 mod_pagespeed/1.9.32.1
0-7423"
Where 172.218.???.??? is my public IP address of my home ISP, redacted for obvious reasons.
This forces me to use a insecure purge location block:
Is there a workaround to this?
The text was updated successfully, but these errors were encountered: