[
https://issues.apache.org/jira/browse/SLING-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181019#comment-17181019
]
Angela Schreiber commented on SLING-9622:
-----------------------------------------
[~rombert], i can confirm that [~cziegeler] created an initial POC adding
{{ResourceResolver.resolve}} in {{SlingAuthenticator.isAnonAllowed}} but
abandoned it for performance and risk considerations, which I agreed with. That
initial POC did (obviously) address the nested vanity-path scenario, which is
now not working.
To add to your reasoning about {{ResourceMapper}}: from what I understand it's
responsibility is to give the mappings of a given resource path (not the other
way round)... so, it is not only that it can't help, it shouldn't.
Also (taking it a bit further to the Auth-Requirement-Registration) it would
feel quite wrong (and would likely not scale) if we ended up registering
separate auth-requirements for all vanity-paths that might exist in the subtree.
Some unsorted thoughts looking at the authenticator and resourceresolver code
base:
- {{SlingAuthenticator.isAnonAllowed}}: {{isNodeRequiresAuthHandler(path,
holder.path)}} essential does a simple path comparison (isEqualOrDescendant)
and therefore is not suited to handle the vanitypath that does not reveal that
it in fact points to a (child) resource that requires authentication.
- {{SlingAuthenticator.isAnonAllowed}}: So, from a distant POV it seems like
{{getPath(request)}} would (once again) be a natural candidate for identifying
if the request points to a vanity path... (without using
{{ResourceResolver.resolve}} excessively for every single request)
- Looking at {{org.apache.sling.resourceresolver.impl.mapping.MapEntries}} I
get the impression that the information about whether a given path is a vanity
path or not is not remembered with the mapping. If that is correct it means
that there is no short-cut to find out if a given path is a vanity path. Maybe
something along that line would be needed in the resourceresolver-API/Impl in
order to be able to identify if a given request points to a vanity path and to
have means to resolve it in a performant way?
wdyt?
> Avoid registration of auth requirements for aliases and vanity paths
> --------------------------------------------------------------------
>
> Key: SLING-9622
> URL: https://issues.apache.org/jira/browse/SLING-9622
> Project: Sling
> Issue Type: Improvement
> Components: Authentication
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: Auth Core 1.5.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Right now when auth requirements are registered, they need to be registered
> for the resource path, as well as all vanity paths and potentially all
> combinations of aliases for that path. First of all, this creates potentially
> a lot of auth requirements for a single path, but as well requires that the
> registrar of the auth requirement to be aware of vanity paths and aliases and
> do the right thing and update the auth requirements whenever there are
> changes.
> We should avoid these additional registrations and processing.
> The SlingAuthenticator is currently checking the request path against the
> auth requirements. We could change this with checking the resolved path. So
> the authenticator could use a service user resolver and resolve the path and
> then check the auth requirements.
> This avoids all the extra work for the registrar of the auth requirements,
> but comes with the additional cost of a resolve call per request
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
