[ 
https://issues.apache.org/jira/browse/SLING-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181313#comment-17181313
 ] 

Robert Munteanu commented on SLING-9622:
----------------------------------------

[~angela] - a quick note while trying to understand the {{MapEntries}} logic - 
it seems to me that vanity paths and mapping entries ( /etc/map ) are treated 
in a similar manner, and looking at 
https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#mapping-entry-specification-1
 I think it's possible for /etc/map entries to 'jump' just like vanity paths.

If that is correct, then the problem is no longer confined to a quick (java) 
map lookup for vanity paths, we also need to take into account {{/etc/map}} 
rules. The ResourceResolver also does that, but this is where things start to 
get expensive...

> 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)

Reply via email to