I like your idea of hooking into the existing URI context processing,
especially because you would want to have the mapping occur after URL
manipulation (I think). My thoughts based on what has been said above:
1. Hook into the existing URI context, and implement the processing
wherever URIs are processed (either automatic via context sensitive
handling built into HTL, or manual whenever context='uri' ise set for an
expression).
2. Have a configuration (CAConfig / OSGi / whatever) to drive whether to
map URIs or not for a given path and/or (super) resource type.
3. Have a local configuration to override the default that is set in the
previous value, like your mapUri, but with a boolean value to turn it
on/off (mapUri=true / mapUri=false)
The reason I think both the global config and the local config are
necessary: JSON or some JS objects in HTL scripts (thinking on how many
times I had to go back and change a Sling Model to add URI mapping, because
a specific Sling-based product that uses a servlet filter does not/cannot
map values in JS/JSON).
-Paul
On Fri, Sep 11, 2020 at 8:15 AM Georg Henzler <ghenz...@apache.org> wrote:
> Hi Radu,
>
>
> >> 1. Per URI as mentioned in template:
> >> <a href="${'/content/path/to/page.html' @ mapUri}"/>
> >
> > This could work - it would be a Sling-specific option and we’ve done
> > this in the past in https://issues.apache.org/jira/browse/SLING-5812
> > <https://issues.apache.org/jira/browse/SLING-5812>. The option would
> > introduce a new runtime call to the new SPIs.
>
> I quickly tested this with minor changes to
> URIManipulationFilterExtension
> and URIManipulationFilter and it worked fine - but as said it's
> tedious and error prone to go this route, it should rather be a cross
> cutting concern
>
> >> 3. Per global OSGi configuration
> >>
> > How would we handle 3?
>
> So one simple naive way would be to hook into [1], check for the
> "uri" context and call the map API method on the value. The probably
> clean way (I don't know this code very well) is to create a dedicated
> filter that gets to see all properties similar to the XSSFilter (and
> adjusts uri values only).
>
> I also think conceptually it also fits in well with the "automatic
> context sensitivity" in the spec [2] (just another aspect compared to
> XSS). While the template/spec does not change, the implementation
> takes care of the handling and configuration, this is true for XSS
> today and would also hold true for mapping of URIs.
>
> -Georg
>
>
> [1]
>
> https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/blob/eb8891e89caef2993f4cdab0fbe764a7695ec0e8/src/main/java/org/apache/sling/scripting/sightly/impl/filter/XSSFilter.java#L51
>
> [2]
>
> https://github.com/adobe/htl-spec/blob/1.2/SPECIFICATION.md#113-context-sensitive
>
