Generate Access Rules from Role Configuration

role description as documenation reference:
https://github.com/wcm-io-devops/conga-aem-definitions/blob/develop/conga-aem-definitions/src/main/roles/aem-dispatcher.yaml

this is implemented, together with some major refactorings:

1. i decided to directly support both dispatcher filter rules and httpd allow/deny rules - and to use them in parallel for different usecases. with the latest additions in AEM dispatcher 4.2.0 (regex support, support for directly filtering for extensions, selectors etc.) it is much more easier to do the "security/anti-content-grabbing" filtering in dispatcher.any. i've left only controlling the access to the admin consoles in the httpd config.

2. thus i introduced two new list variables with an object structure for defining the rules at dispatcher.filter and httpd.accessRestriction.locationFilter. see aem-dispatcher.yaml role file for a detailed description.

3. i also added a bunch of additional parameters for making the dispatcher.any more configurable, e.g. for cache and invalidation rules. documented in aem-dispatcher.yaml

4. and last but not least i restructured most of the dispatcher role config parameter name to clearly distinguish between httpd (targeting apache and vhost files) and dispatcher (targeting dispatcher config files). a mapping table for the parameters is included in the 0.x -> 1.x migration guide https://wcm-io.atlassian.net/wiki/x/AQDRAw

5. i added sensible defaults to all parameters matching the config from the 0.x roles, and updated with some new aspects defined in the dispatcher config examples from latest AEM dispatcher releases

after playing around with different approaches for declaring the filter rules (and solving https://wcm-io.atlassian.net/browse/WDCONGA-9#icft=WDCONGA-9) martins apporach from the ticket description works as well, and is more flexible then my approach from my last comment.

but before we start inventing a new syntax for declaring filter rules, we might also take over excactly the same syntax as used in dispatcher.any files:
https://docs.adobe.com/docs/en/dispatcher/disp-config.html#par_134_32_0009

and just transform it to apache httpd config rules (we can write a custom handlebars helper for this in the conga aem plugin). maybe add an extra support for the admin access filter rules, which do not block in general, but allow access from certain ip ranges.

my proposal would be something like this - add a new set of parameters to the dispatcher role configurations. we cannot use complex structures as CONGA parameters, only nested maps.

no patterns are allowed for locations or selectors (can be done with custom http config). the strings are escaped or converted into a pattern in the template. locations are checked with "location" directive, selectors if the URI contains the given string at any position.

normaly the list of deny rules is not touched in the environment (it's the list maintained in the role and is updated if new dangerous selectors need to be added). iwth the allow variable it's possibel to override a deny and allow it although its included in the deny list.

from the sling parameters only sling.defaultJsonOutput is relevant for the dispatcher role (the others are relevant for the aem role). if this is set to false, variants like .999.json or .-1.json or .inifinty.json or .tidy.json are denied.

for /dispatcher there is additional special logic depending on dispatcher.allowFlushFrom and dispatcher.allowFlushFromHost.

this should be done together with WDCONGA-14.

this is a good idea.

some deny rules are directly in relation to features in AEM that can be switched on/off - e.g. allowing access to .json or .xml view of nodes or not. if they are allowed on httpd/dispatcher, the feature should be activated in the Sling GET Servlet as well and vice versa.

perhaps we split up this whole selector configuration in a set of feature flags for specific features, and a list of more generic allow/deny patterns which can be overwritten or extended.

for the different pattern formats in dispatcher and httpd: i suppose it's easy to automatically match dispatcher->httpd, but not the other way round. i we want to do this automatic we would need to limit ourselves to the dispatcher rule syntax.