Konrad Windszus wrote > I am not sure either, I would like to hear the opinions of some other Sling > committers on this.
I think we're talking about edge cases here and the cost of doing the resolution / mapping is too high - and it would punish all requests. In addition, the only way to make this work reliable would be to use login administrative - and that's definitely not something we want to do Regards Carsten > Konrad > >> On 10. May 2017, at 14:25, Antonio Sanso <asa...@adobe.com.INVALID> wrote: >> >> hi Konrad >> >> On May 10, 2017, at 2:16 PM, Konrad Windszus <konra...@gmx.de> wrote: >> >>> Hi Antonio, >>> Sorry for the confusion, I was wrongly assuming that you fixed my original >>> concern without checking further in the code. >>> But in fact there are still unexpected corner cases which cover the wrong >>> nodes (see my last comments in SLING-6053). >>> >>> Not sure how to proceed here, but the previous mechanism of prefix path >>> matching was at least easy to describe, although kind of unexpected. Now >>> the more sophisticated matching gives the wrong certainty that you can now >>> easily restrict authentication to certain resource paths (and children) >>> which is not the case because the mechanism still only relies on request >>> paths only (and not on resource paths). >> >> this new mechanism it might be a bit more difficult to describe (nothing >> that a good documentation can’t do though) but for sure it will not >> introduce new corner case. What it will do it is actually managing better >> some of the old corner cases (reducing the number of mistakes) >> >>> >>> The cleanest solution would be IMHO to involve the resource resolver there >>> already, but I haven't checked the implications. >> >> I agree this is the only clean solution but this will have a considerable >> cost. Do we really want to map/resolve at the authentication layer? >> >> regards >> >> antonio >> >>> Konrad >>> >>> >>>> On 10. May 2017, at 14:06, Antonio Sanso <asa...@adobe.com.INVALID> wrote: >>>> >>>> hi Konrad, >>>> >>>> I am confused now since you were in favor for it in the first place … >>>> https://issues.apache.org/jira/browse/SLING-6053?focusedCommentId=16000473&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16000473 >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On May 10, 2017, at 11:21 AM, Konrad Windszus <konra...@gmx.de> wrote: >>>> >>>>> Sorry for insisting on it, but I am still not 100% convinced the patch >>>>> for SLING-6053 works correctly. >>>>> See my comment in >>>>> https://issues.apache.org/jira/browse/SLING-6053?focusedCommentId=16004357&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16004357. >>>>> >>>>> The general problem is that in Sling you cannot uniquely extract the >>>>> resource path from a given url (because resource names may contain "." as >>>>> well). >>>>> Thanks, >>>>> Konrad >>>>> >>>>>> On 10. May 2017, at 11:04, Antonio Sanso <asa...@adobe.com.INVALID> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We solved 1 issue in this release: >>>>>> https://issues.apache.org/jira/browse/SLING-6053 >>>>>> >>>>>> Staging repository: >>>>>> https://repository.apache.org/content/repositories/orgapachesling-1716/ >>>>>> >>>>>> You can use this UNIX script to download the release and verify the >>>>>> signatures: >>>>>> http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh >>>>>> >>>>>> Usage: >>>>>> sh check_staged_release.sh 1716 /tmp/sling-staging >>>>>> >>>>>> Please vote to approve this release: >>>>>> >>>>>> [ ] +1 Approve the release >>>>>> [ ] 0 Don't care >>>>>> [ ] -1 Don't release, because ... >>>>>> >>>>>> This majority vote is open for at least 72 hours. >>>>> >>>> >>> >> > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
