[
https://issues.apache.org/jira/browse/SLING-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581765#comment-13581765
]
Ian Boston commented on SLING-2592:
-----------------------------------
Ok thanks for the updated description, I now understand why it works.
This patch has downstream security implications. Description of behaviour
first, question at the bottom of this comment.
For the record, before the patch, if a specific AuthenticationHandler was
registered against a scheme (eg https or http) then that registration would
always get overridden by the default set of registrations. If there were none
for the host, then all that would be left is the default for protocol and
default for path.
The patch ensures that specific registrations of AuthenticationHandlerHolders
are remain available and are not overridden by the the default.
This patch fixes the bug mentioned as
org.apache.sling.auth.core.impl.SlingAuthenticator.isAnonAllowed(HttpServletRequest)
now callls AuthenticationRequirementHolder.requiresAuthentication() will now
call all registered AuthenticationRequirementHolders.
The side effects of the patch are that
org.apache.sling.auth.core.impl.SlingAuthenticator.handleSecurity(HttpServletRequest,
HttpServletResponse)
org.apache.sling.auth.core.impl.SlingAuthenticator.login(HttpServletRequest,
HttpServletResponse)
org.apache.sling.auth.core.impl.SlingAuthenticator.logout(HttpServletRequest,
HttpServletResponse)
will now call all AbstractAuthenticationHandlerHolder(s) for paths that start
with the holder.path. Previously they only called the default.
I think the change (which is logically correct) has the potential to activate
previously dormant AuthenticationRequirementHolder(s) in the field for login
and handleSecurity..
Whats the correct procedure for applying this and ensuring downstream users
know that the security behaviour may change on the next release ?
> Anonymous/nonanonymous access grant is not effective for mapped paths.
> ----------------------------------------------------------------------
>
> Key: SLING-2592
> URL: https://issues.apache.org/jira/browse/SLING-2592
> Project: Sling
> Issue Type: Bug
> Components: Authentication
> Affects Versions: Auth Core 1.0.6
> Reporter: Dominik Smogór
> Assignee: Ian Boston
> Attachments: authcore-SLING-2592.patch
>
>
> I'm using sling with CQ 5.4 with a custom authentication handler and custom
> auth info provider (one that sets "sling.auth.requirements" property). The
> handler expects requestCredentials to be called for some paths. When any of
> them is mapped (requestResolver.map returns full http URL) the
> SlingAuthenticator fails to recognize path as non anonymous and the request
> processing ends with 404 error instead of login page redirect.
> What is changed by the path:
> Without the patch, the following code:
> final Map<String, List<Type>> byHostMap = cache.get(request.getScheme());
> if ( byHostMap != null ) {
> result[0] = byHostMap.get(hostname);
> result[1] = byHostMap.get("");
> }
> was not effective.
> The code retrieves a Holder from the cache keeping mapped paths as mapped
> paths include both scheme and hostname.
> The returned result array is processed top-bottom by the caller.
> Thanks to the patch, a shortened (mapped) path can be found in the "http
> indexed" cache, and authentication request can be issued.
> The change might possibly cause existing code that, is based on this
> misbehavior to no longer work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
