[jira] [Commented] (SLING-2592) Anonymous/nonanonymous access grant is not effective for mapped paths.

2012-09-05 Thread JIRA

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

Dominik Smogór commented on SLING-2592:
---

The patch is licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */

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

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


[jira] [Commented] (SLING-2592) Anonymous/nonanonymous access grant is not effective for mapped paths.

2013-02-18 Thread Ian Boston (JIRA)

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

Ian Boston commented on SLING-2592:
---

The patch looks good, however I cant see how it addresses the reported issue.

It does ensure that if the requested hostname is in the cache for both the 
request scheme (eg https) and the default scheme "", then both sets of 
PathBasedHolders are made available to the caller. Previously the specific for 
the scheme was overwritten by the default for the scheme (hence why the patch 
makes sense).

Perhaps the description of the report is wrong. 
I am not keen on applying the patch until I know why if fixes the problem in 
the description.

I also notice that there is some out of band typing in this area.
org.apache.sling.auth.core.impl.PathBasedHolderCache.findApplicableHolder(HttpServletRequest)
 returns a List and when called its cast to 
List which although correct at the moment 
may not remain correct. It could result in a classcast exception if there is 
anything else implementing a PathBasedHolder. (not certain how important that 
is).


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

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


[jira] [Commented] (SLING-2592) Anonymous/nonanonymous access grant is not effective for mapped paths.

2013-02-19 Thread Ian Boston (JIRA)

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


[jira] [Commented] (SLING-2592) Anonymous/nonanonymous access grant is not effective for mapped paths.

2013-02-19 Thread Felix Meschberger (JIRA)

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

Felix Meschberger commented on SLING-2592:
--

I think the patch is technically correct because it probably implements the 
original intention of SLING-15080 (where this code probably comes from): Return 
a list of up 0, 2, or 4 entries depending on map contents and applicability.

I am +1 on applying it.

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


[jira] [Commented] (SLING-2592) Anonymous/nonanonymous access grant is not effective for mapped paths.

2013-02-20 Thread Ian Boston (JIRA)

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

Ian Boston commented on SLING-2592:
---

Patch applied, thank you everyone for being patient and reviewing.

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