I was able to use {stat} this way...
records.config:
CONFIG proxy.config.http_ui_enabled INT 2
CONFIG proxy.config.http.enable_http_info INT 1
remap.config
map /_stat/ http://{stat} @action=allow @src_ip=127.0.0.1
$ curl localhost:<port>/_stat/ -s
<pre>
proxy.config.proxy_name=<hostname>
…
proxy.process.update.state_machines=0
</pre>
I'm only using the output to parse and report metrics into monitoring, so I
didn't require access outside of localhost.
On May 1, 2012, at 6:27 PM, Leif Hedstrom <[email protected]> wrote:
> On 5/1/12 6:59 PM, Van Doorn, Jan R wrote:
>> On 05/01/2012 05:34 PM, Leif Hedstrom wrote:
>>> On 5/1/12 5:29 PM, tom ryan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I looked in the documentation, tried some different remap configs, but
>>>>>> can't make it do what I want...
>>>>>>
>>>>>> I'd like to use the stats_over_http plugin, but restrict the clients
>>>>>> that can get to it to just a couple of addresses. Is that possible?
>>>>>> What
>>>>>> is the best way to that?
>>>>>>
>>>>> No way at this point.
>>>> -snip-
>>>>
>>>> What's about the doc reference to rules like:
>>>>
>>>> map http://localhost/stat/ http://{stat}
>>>>
>>>> as seen in
>>>> https://cwiki.apache.org/TS/faq.html#FAQ-httpui
>>>>
>>> I don't think that will work, since this is a server intercept plugin
>>> (and therefore, doesn't require a remap). You can try it, and see what
>>> happens.
>>>
>> I tried a couple of variations like that, and couldn't make it work. I
>> really just need a simple client IP address check, so, I think I'm just
>> going to reuse some of the code from the redirect-1 plugin sample, like
>> in the diff below.
>>
>> Leif: your config suggestions with the X-TS-Stats-Auth* header seem
>> pretty cool to me, but, like I said - I just need a quick IP check for
>> now, and I would think the below is a safe and simple hack?
>>
>>
>
>
> Yeah, I intentionally wanted to avoid that, since managing IP ACLs is a PITA,
> and without support for IP-ranges etc. it's not particularly user friendly
> (and perhaps not even usable for a large portion of users). If we could
> expose the internal code that does already deal with this to our TSAPI's,
> that would be the way to go (since then you get all the optimized range
> support etc.).
>
>
> Alan, can we expose any of those IP ranges / filters you implemented in TSAPI
> ?
> -- leif
>
