v3 Status Handler CIDR ACL

[Tom Zeller]

>>> It's just different from the default Jetty distribution behavior
>>
>>I guess what I did with jetty-base in idp-distribution is confusing,
>>I'll try to explain a little.
>>
>>I was hoping to provide IdPv3 as a Jetty module, comprised of
>>modules/idp.mod and start.d/idp.ini, so that it would follow the Jetty
>>9.1+ convention for deployment into a deployer's existing Jetty
>>instance. So that's why all of the properties are in start.d/idp.ini.
>
> That's all simple enough, the problem is that nobody's going to expect
> localhost as a default.

Right, I see that now.

> Secondly, I think I would have just provided http/https/ssl.ini files
> directly instead of duplicating properties in a new idp module. I think
> it's less clear to create a new module than just configure the existing
> ones, because then people using their own Jetty can see what's being done
> as a direct comparison.

Right, I understand about direct comparison, that was my intention,
and providing http/https/ssl/dta-ssl is where I started, but ... (see
below)

> As an aside, Jetty's ini thing is well-meaning but pointless. You end up
> in most cases needing to create your own copies of the various xml files
> anyway, even if it's just to embed new <Property> references for things
> they didn't account for. It's much like our situation; properties are ok,
> but eventually you hit diminishing returns with them and just edit the XML.

... so I needed to customize jetty-ssl.xml and jetty-deploy anyway,
and providing more XML and ini files did not seem less confusing.

Also, there was a different start.d mechanism that was talked about
than what actually shipped, and after trying the IdP module I sort-of
gave up thinking that tying ourselves to Jetty's paradigm might be
brittle, so I ended up thinking a monolithic etc/jetty.xml was the way
to go.

I can work through a more modular example again while making changes
to not default to localhost.