[
https://issues.apache.org/jira/browse/SLING-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180841#comment-17180841
]
Robert Munteanu commented on SLING-9622:
----------------------------------------
The changes from the auth.core module and the resourceresolver seem to work
together quite well, but Angela discovered one scenario where this breaks down.
Assume the following structure
{noformat}
- parent [vanityPath:/p_vanity]
\- child [vanityPath:/c_vanity]
{noformat}
If {{/parent}} is a protected resource with a registered authentication
requirement, {{/parent/child}} will be included in that requirement. Ance since
we generate all variations, {{/p_vanity}} will be registered as a different
authentication requirement.
Unfortunately {{/c_vanity}} will not be included, and this bypasses the
authentication requirement for the parent node.
-----
The {{ResourceMapper}} can not unfortunately help here, as the mapping comes
from a child path, not from the one where the requirements are set. The
{{SlingAuthenticatorServiceListener}} will not even know about the child path,
as it just creates the authentication requirements, and those are based on the
parent.
It would be simple ( I think ) to resolve the given path in the
{{SlingAuthenticator}}, but I remember Carsten speaking against it due to
performance issue - we really should only use the given path. There may be a
way to just check if the request is a vanity path and then point it to the
actual resources, but that would be moving truly unrelated concerns in the
{{SlingAuthenticator}}, which is complex and sensitive. Moreover, it's
completely against the spirit of the change we're trying to make.
Right now I don't have a great (or good) idea on how to fix this scenario.
> 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)
