[
https://issues.apache.org/jira/browse/SLING-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182336#comment-17182336
]
Carsten Ziegeler commented on SLING-9622:
-----------------------------------------
I think the design flaw - which we have from the start of Sling - is that we
added resolve() to the resource resolver - we have touched on this over the
past years several times but never changed anything - It would have probably be
better to first resolve an incoming path (without requiring authentication) and
then invoking the authentication and then creating a resource resolver with the
authentication info. With our current design, we need to create a resource
resolver (for a service user), resolve(), authenticate, create a resource
resolver with the auth info and then resolve() again with that resolver. We
could come up with a hack to magically pass the information from the first
resolve() call to the second one and reuse it, mitigating the performance
problem. But that would be very ugly
Changing the way, Sling deals with incoming requests is probably too much of a
change as well.
So I think we need to get intp a compromise here: improve the situation as much
as possible without creating too much of a mess :)
Before the changes of this issue, a registrar of auth requirements was
responsible to also deal with vanity paths and aliases and do proper
registrations for those combinations as well. Clearly, that is too much of a
burden for a registrar. We can improve this in auth core with the mentioned
changes and handle vanity paths and alias for an auth registration. I think
that's a reasonable improvement.
As has been discovered, there is still an issue with nested vanity paths *and*
auth requirements - the question is now how likely this scenario is. So far
this never worked, so if we now don't support it with the changes, we're not
making it worse. We can just document it, and that's it.
The same is probably true for /etc/map using path mappings; This never worked
before and still is not. Again, let's document it.
Long term, we should change the way resolving is done in Sling,
> 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)
