[jira] [Commented] (SLING-6901) Remove commons.json from org.apache.sling.jcr.js.nodetypes

[Sandro Boehme (JIRA)]

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

Sandro Boehme commented on SLING-6901:
--

I'am the maintainer for sling.jcr.js.nodetypes. It is needed for the Sling 
Resource Editor. I'll take the task and care about it as soon as I have the 
time to do it. 

> Remove commons.json from org.apache.sling.jcr.js.nodetypes
> --
>
> Key: SLING-6901
> URL: https://issues.apache.org/jira/browse/SLING-6901
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Karl Pauls
>Assignee: Sandro Boehme
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-6901) Remove commons.json from org.apache.sling.jcr.js.nodetypes

[Sandro Boehme (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandro Boehme reassigned SLING-6901:


Assignee: Sandro Boehme

> Remove commons.json from org.apache.sling.jcr.js.nodetypes
> --
>
> Key: SLING-6901
> URL: https://issues.apache.org/jira/browse/SLING-6901
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Karl Pauls
>Assignee: Sandro Boehme
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release JSPC Maven Plugin 2.1.0

[Daniel Klco]

+1

On Mon, Jun 12, 2017 at 1:23 PM, Stefan Seifert 
wrote:

> +1
>
> i've also published the auto-generated plugin documentation as maven site
> [1]
>
> stefan
>
> [1] http://sling.apache.org/components/jspc-maven-plugin/
>
>
>

Re: [VOTE] Release Apache Sling Security 1.1.4

[Daniel Klco]

+1

On Tue, Jun 13, 2017 at 5:47 AM, Antonio Sanso 
wrote:

> Hi,
>
> We solved 3 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12338749
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1742/
>
> 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 1742 /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.

Re: Resource Type Inheritance fully supported for the Sling Servlet Resolver?

[Konrad Windszus]

Ok, forget about this issue here. Actually the Sling Servlet Resolver can deal 
fine even with transitive resource super types. In my case the issue was within 
the 
https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
 which was throwing a 404.

> On 13. Jun 2017, at 16:51, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> "Deriving" in this context means: having a sling:resourceSuperType set.
>> So in my example "componenta" has sling:resourceSuperType set to 
>> "core/wcm/components/image/v1/image" and "componentb" has 
>> sling:resourceSuperType set to "componenta".
>> 
> Got it, thanks - I think that should work...has componenta a different
> resource type than componenta? (not sure if this makes a difference though)
> 
> Regards
> Carsten
> 
>>> On 13. Jun 2017, at 16:24, Carsten Ziegeler  wrote:
>>> 
>>> Konrad Windszus wrote
 Hi,
 Currently if a servlet is registered for a specific resource type, e.g. 
 like the one from 
 https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
  it is correctly resolved for a resource with a resource type "componenta" 
  directly having "core/wcm/components/image" as resource super type. But 
 as soon as an additional inheritance level comes into play, e.g. 
 "componenta" deriving from "core/wcm/components/image" and "componentb" 
 deriving from "componenta" the servlet is no longer being resolved for 
 resources having the resource type "componentb" (and instead a 404 is 
 returned, because no other servlet/script for the according selector is 
 registered). Is that a known limitation of the Servlet Resolver?
>>> 
>>> I'm not quiet sure what you mean with "deriving"?
>>> 
>>> Regards
>>> Carsten
>>> 
 Thanks,
 Konrad
 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>> 
>> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Resource Type Inheritance fully supported for the Sling Servlet Resolver?

[Carsten Ziegeler]

Konrad Windszus wrote
> "Deriving" in this context means: having a sling:resourceSuperType set.
> So in my example "componenta" has sling:resourceSuperType set to 
> "core/wcm/components/image/v1/image" and "componentb" has 
> sling:resourceSuperType set to "componenta".
> 
Got it, thanks - I think that should work...has componenta a different
resource type than componenta? (not sure if this makes a difference though)

Regards
Carsten

>> On 13. Jun 2017, at 16:24, Carsten Ziegeler  wrote:
>>
>> Konrad Windszus wrote
>>> Hi,
>>> Currently if a servlet is registered for a specific resource type, e.g. 
>>> like the one from 
>>> https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
>>>  it is correctly resolved for a resource with a resource type "componenta"  
>>> directly having "core/wcm/components/image" as resource super type. But as 
>>> soon as an additional inheritance level comes into play, e.g. "componenta" 
>>> deriving from "core/wcm/components/image" and "componentb" deriving from 
>>> "componenta" the servlet is no longer being resolved for resources having 
>>> the resource type "componentb" (and instead a 404 is returned, because no 
>>> other servlet/script for the according selector is registered). Is that a 
>>> known limitation of the Servlet Resolver?
>>
>> I'm not quiet sure what you mean with "deriving"?
>>
>> Regards
>> Carsten
>>
>>> Thanks,
>>> Konrad
>>>
>>
>>
>>
>>
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Resource Type Inheritance fully supported for the Sling Servlet Resolver?

[Konrad Windszus]

"Deriving" in this context means: having a sling:resourceSuperType set.
So in my example "componenta" has sling:resourceSuperType set to 
"core/wcm/components/image/v1/image" and "componentb" has 
sling:resourceSuperType set to "componenta".

> On 13. Jun 2017, at 16:24, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> Hi,
>> Currently if a servlet is registered for a specific resource type, e.g. like 
>> the one from 
>> https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
>>  it is correctly resolved for a resource with a resource type "componenta"  
>> directly having "core/wcm/components/image" as resource super type. But as 
>> soon as an additional inheritance level comes into play, e.g. "componenta" 
>> deriving from "core/wcm/components/image" and "componentb" deriving from 
>> "componenta" the servlet is no longer being resolved for resources having 
>> the resource type "componentb" (and instead a 404 is returned, because no 
>> other servlet/script for the according selector is registered). Is that a 
>> known limitation of the Servlet Resolver?
> 
> I'm not quiet sure what you mean with "deriving"?
> 
> Regards
> Carsten
> 
>> Thanks,
>> Konrad
>> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Resource Type Inheritance fully supported for the Sling Servlet Resolver?

[Carsten Ziegeler]

Konrad Windszus wrote
> Hi,
> Currently if a servlet is registered for a specific resource type, e.g. like 
> the one from 
> https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
>  it is correctly resolved for a resource with a resource type "componenta"  
> directly having "core/wcm/components/image" as resource super type. But as 
> soon as an additional inheritance level comes into play, e.g. "componenta" 
> deriving from "core/wcm/components/image" and "componentb" deriving from 
> "componenta" the servlet is no longer being resolved for resources having the 
> resource type "componentb" (and instead a 404 is returned, because no other 
> servlet/script for the according selector is registered). Is that a known 
> limitation of the Servlet Resolver?

I'm not quiet sure what you mean with "deriving"?

Regards
Carsten

> Thanks,
> Konrad
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Resource Type Inheritance fully supported for the Sling Servlet Resolver?

[Konrad Windszus]

Hi,
Currently if a servlet is registered for a specific resource type, e.g. like 
the one from 
https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java
 it is correctly resolved for a resource with a resource type "componenta"  
directly having "core/wcm/components/image" as resource super type. But as soon 
as an additional inheritance level comes into play, e.g. "componenta" deriving 
from "core/wcm/components/image" and "componentb" deriving from "componenta" 
the servlet is no longer being resolved for resources having the resource type 
"componentb" (and instead a 404 is returned, because no other servlet/script 
for the according selector is registered). Is that a known limitation of the 
Servlet Resolver?
Thanks,
Konrad

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan commented on SLING-6422:
---

Thanks

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit JCR 1.1.6
>
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Slingstart Archetype version 1.0.2

[Daniel Klco]

+1

On Mon, Jun 12, 2017 at 1:22 PM, Stefan Seifert 
wrote:

> +1
>
>

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6422:


I have added a few examples with restrictions at 
https://sling.apache.org/documentation/bundles/repository-initialization.html

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit JCR 1.1.6
>
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Bertrand Delacretaz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz resolved SLING-6422.

   Resolution: Fixed
 Assignee: Bertrand Delacretaz
Fix Version/s: Repoinit JCR 1.1.6

Ok, thanks! I have committed your contribution in 
http://svn.apache.org/r1798602 including my minor changes.

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
>Assignee: Bertrand Delacretaz
> Fix For: Repoinit JCR 1.1.6
>
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan commented on SLING-6422:
---

[~bdelacretaz] Comparison function looks good to me, yes sorting should not be 
an issue on small arrays. Although, it would have been great if jackrabbit 
clearly documented ordered ness of the values :-)

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Plan to release Testing Clients 1.1.0, Testing Email 1.0.0

[Robert Munteanu]

Hi,

I plan to release the two mentioned modules late tomorrow or Thursday.
If anyone sees a reason to delay please say so.

Robert

[jira] [Resolved] (SLING-6954) Add client support for the org.apache.sling.testing.email bundle

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-6954.

Resolution: Fixed

Fixed in [r1798597|https://svn.apache.org/r1798597]

> Add client support for the org.apache.sling.testing.email bundle
> 
>
> Key: SLING-6954
> URL: https://issues.apache.org/jira/browse/SLING-6954
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Apache Sling Testing Clients 1.1.0
>
>
> With the features added in SLING-6949 it makes sense to add a thin 
> client-side layer to make this simpler to use.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6949) Create testing utilities for email-enabled applications

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-6949.

   Resolution: Fixed
Fix Version/s: Testing Email 1.0.0

Added extra logging in [r1798597|https://svn.apache.org/r1798597]

> Create testing utilities for email-enabled applications
> ---
>
> Key: SLING-6949
> URL: https://issues.apache.org/jira/browse/SLING-6949
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Testing Email 1.0.0
>
>
> When working with email-enabled applications it is sometimes desirable to 
> interact with the emails send by the applications, either by verifying the 
> contents of the emails or just validating that a certain email is sent.
> A good solution for this is 
> [Wiser|https://github.com/voodoodyne/subethasmtp/blob/master/Wiser.md], which 
> works quite well.
> One scenario where this does not apply is when the application under test is 
> running as a container, and it cannot access the host application to deliver 
> emails to the Wiser instance.
> To have an unitary approach I propose that we create an OSGi bundle which 
> wraps Wiser and starts in the Sling application. The messages received by 
> Wiser can then be read using an HTTP API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6954) Add client support for the org.apache.sling.testing.email bundle

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6954:
--

 Summary: Add client support for the org.apache.sling.testing.email 
bundle
 Key: SLING-6954
 URL: https://issues.apache.org/jira/browse/SLING-6954
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Apache Sling Testing Clients 1.1.0


With the features added in SLING-6949 it makes sense to add a thin client-side 
layer to make this simpler to use.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6422:


I understand we might have assumptions about the ordering of restrictions in 
various places but I'd prefer not having them in Sling if we can avoid that. 
That's code that we'll rarely touch, so the more future proof the better.

I've added a simple comparison method which doesn't care about ordering and 
should be good enough if the arrays are small, WDYT? 

At https://github.com/apache/sling/pull/242 - that's your patch with the 
addition of my {{compareArrays}} method.

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE] Release Apache Sling Security 1.1.4

[Antonio Sanso]

Hi,

We solved 3 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12338749

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1742/

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

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-6422:
---

GitHub user bdelacretaz opened a pull request:

https://github.com/apache/sling/pull/242

SLING-6422: add to Nitin's patch a comparison that ignores ordering of 
restrictions



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bdelacretaz/sling SLING-6422

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/242.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #242


commit 4aa930056d48655995629b9253edd1bd394f7ecb
Author: Nitin Nizhawan 
Date:   2017-05-16T11:01:56Z

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Interpret parsed restriction clauses from repoinit

commit be2e488e33b01cf7fde54643e86489da47510d4a
Author: Bertrand Delacretaz 
Date:   2017-06-13T11:58:40Z

Merge remote-tracking branch 'nitin/nnizhawa/SLING_6422ApplyRestrictionsV3' 
into SLING-6422

commit 8a3c4869a9416ee16cf441dd3babf85de6c9d73f
Author: Bertrand Delacretaz 
Date:   2017-06-13T12:44:59Z

SLING-6422 - compare arrays regardless of their ordering




> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6951) Sling Resource Merger: hideChildren="*" incorrectly hides nested local children

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6951:


After applying this fix, there was another edge case unveiled with underlying 
grandchildren not correctly hidden. This is fixed with 
[r1798594|https://svn.apache.org/r1798594].

> Sling Resource Merger: hideChildren="*" incorrectly hides nested local 
> children
> ---
>
> Key: SLING-6951
> URL: https://issues.apache.org/jira/browse/SLING-6951
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.3.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Resource Merger 1.3.4
>
>
> It seems that the changes to the wildcard handling of the ResourceMerger 
> being done in SLING-5468 only work correctly on the first level. Any deeper 
> nested local nodes are also not displayed when using 
> {{sling:hideChildren="*"}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] sling pull request #242: SLING-6422: add to Nitin's patch a comparison that ...

[bdelacretaz]

GitHub user bdelacretaz opened a pull request:

https://github.com/apache/sling/pull/242

SLING-6422: add to Nitin's patch a comparison that ignores ordering of 
restrictions



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bdelacretaz/sling SLING-6422

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/242.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #242


commit 4aa930056d48655995629b9253edd1bd394f7ecb
Author: Nitin Nizhawan 
Date:   2017-05-16T11:01:56Z

SLING-6422, Allow for specifying oak restrictions with repoinit

   - Interpret parsed restriction clauses from repoinit

commit be2e488e33b01cf7fde54643e86489da47510d4a
Author: Bertrand Delacretaz 
Date:   2017-06-13T11:58:40Z

Merge remote-tracking branch 'nitin/nnizhawa/SLING_6422ApplyRestrictionsV3' 
into SLING-6422

commit 8a3c4869a9416ee16cf441dd3babf85de6c9d73f
Author: Bertrand Delacretaz 
Date:   2017-06-13T12:44:59Z

SLING-6422 - compare arrays regardless of their ordering




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (SLING-6561) Test case for SLING-6271

[Antonio Sanso (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonio Sanso updated SLING-6561:
-
Fix Version/s: Security 1.1.4

> Test case for SLING-6271
> 
>
> Key: SLING-6561
> URL: https://issues.apache.org/jira/browse/SLING-6561
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Rob Ryan
>Assignee: Antonio Sanso
>Priority: Minor
> Fix For: Security 1.1.4
>
> Attachments: sling6271test.patch
>
>
> Attached is a proposed unit test for the issue reported in SLING-6271.
> In the case of setContentType being called before and after 
> requestDispatcher.forward() each with the same content type SLING-6271 
> reported that the response ended up with no content type header.
> The key aspect of forward() was that it calls reset() which clears all 
> headers on the response.
> The attached patch adds test cases for two scenarios around this: in case a 
> content disposition header is also needed, or in case a content disposition 
> header is not needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-6937) Referrer Filter: Allow Regex User Agent Exclusions

[Antonio Sanso (JIRA)]

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

Antonio Sanso edited comment on SLING-6937 at 6/13/17 12:18 PM:


fix in rev. r1798584 Thanks a lot [~djaeggi] for the patch. Thanks


was (Author: asanso):
fix in rev. r1784271 Thanks a lot [~djaeggi] for the patch. Thanks

> Referrer Filter: Allow Regex User Agent Exclusions
> --
>
> Key: SLING-6937
> URL: https://issues.apache.org/jira/browse/SLING-6937
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Security 1.1.2
>Reporter: Dominique Jäggi
>Assignee: Antonio Sanso
> Fix For: Security 1.1.4
>
> Attachments: 
> _SLING_6937___Referrer_Filter__Allow_Path_Exclusions-2.patch
>
>
> For some cases it would be desirable to skip the referrer check altogether 
> for certain resource paths, instead of simply setting "Allow Empty Referrer", 
> thus weakening the security overall instead of only for a well known set of 
> paths for which it would be desirable.
> For this reason i'd like to propose adding a path whitelist to the referrer 
> filter configuration. Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6937) Referrer Filter: Allow Regex User Agent Exclusions

[Antonio Sanso (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonio Sanso resolved SLING-6937.
--
   Resolution: Fixed
Fix Version/s: Security 1.1.4

fix in rev. r1784271 Thanks a lot [~djaeggi] for the patch. Thanks

> Referrer Filter: Allow Regex User Agent Exclusions
> --
>
> Key: SLING-6937
> URL: https://issues.apache.org/jira/browse/SLING-6937
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Security 1.1.2
>Reporter: Dominique Jäggi
>Assignee: Antonio Sanso
> Fix For: Security 1.1.4
>
> Attachments: 
> _SLING_6937___Referrer_Filter__Allow_Path_Exclusions-2.patch
>
>
> For some cases it would be desirable to skip the referrer check altogether 
> for certain resource paths, instead of simply setting "Allow Empty Referrer", 
> thus weakening the security overall instead of only for a well known set of 
> paths for which it would be desirable.
> For this reason i'd like to propose adding a path whitelist to the referrer 
> filter configuration. Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6951) Sling Resource Merger: hideChildren="*" incorrectly hides nested local children

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved SLING-6951.

Resolution: Fixed

Fixed in [r1798579|https://svn.apache.org/r1798579].

> Sling Resource Merger: hideChildren="*" incorrectly hides nested local 
> children
> ---
>
> Key: SLING-6951
> URL: https://issues.apache.org/jira/browse/SLING-6951
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.3.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Resource Merger 1.3.4
>
>
> It seems that the changes to the wildcard handling of the ResourceMerger 
> being done in SLING-5468 only work correctly on the first level. Any deeper 
> nested local nodes are also not displayed when using 
> {{sling:hideChildren="*"}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: [ANN] Apache Sling 9 Released

[Stefan Seifert]

thanks, robert!

stefan

[jira] [Assigned] (SLING-6937) Referrer Filter: Allow Regex User Agent Exclusions

[Antonio Sanso (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Antonio Sanso reassigned SLING-6937:


Assignee: Antonio Sanso

> Referrer Filter: Allow Regex User Agent Exclusions
> --
>
> Key: SLING-6937
> URL: https://issues.apache.org/jira/browse/SLING-6937
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Security 1.1.2
>Reporter: Dominique Jäggi
>Assignee: Antonio Sanso
> Attachments: 
> _SLING_6937___Referrer_Filter__Allow_Path_Exclusions-2.patch
>
>
> For some cases it would be desirable to skip the referrer check altogether 
> for certain resource paths, instead of simply setting "Allow Empty Referrer", 
> thus weakening the security overall instead of only for a well known set of 
> paths for which it would be desirable.
> For this reason i'd like to propose adding a path whitelist to the referrer 
> filter configuration. Patch attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6953) Move Dockerfile to the launchpad/builder directory

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6953:
--

 Summary: Move Dockerfile to the launchpad/builder directory
 Key: SLING-6953
 URL: https://issues.apache.org/jira/browse/SLING-6953
 Project: Sling
  Issue Type: Improvement
  Components: Launchpad
Reporter: Robert Munteanu
 Fix For: Launchpad Builder 10


If we do that, the dockerfile will get tagged as part of the release and we'll 
be able to participate in the dockerhub automatic builds and then release our 
image as part of the apache org.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6952) Release Sling 10

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6952:
--

 Summary: Release Sling 10
 Key: SLING-6952
 URL: https://issues.apache.org/jira/browse/SLING-6952
 Project: Sling
  Issue Type: Task
  Components: General
Reporter: Robert Munteanu


Never too early to start planning :-)

Documentation at 
https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Launchpad



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6205) Send announcement to u...@sling.apache.org and annou...@apache.org

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-6205.

Resolution: Fixed

> Send announcement to u...@sling.apache.org and annou...@apache.org
> --
>
> Key: SLING-6205
> URL: https://issues.apache.org/jira/browse/SLING-6205
> Project: Sling
>  Issue Type: Sub-task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6194) Release Sling 9

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-6194.

Resolution: Fixed

> Release Sling 9
> ---
>
> Key: SLING-6194
> URL: https://issues.apache.org/jira/browse/SLING-6194
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> Time to release Sling 9.
> Documentation at 
> https://cwiki.apache.org/confluence/display/SLING/Releasing+a+new+version+of+the+Sling+Launchpad



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SLING-6205) Send announcement to u...@sling.apache.org and annou...@apache.org

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned SLING-6205:
--

Assignee: Robert Munteanu

> Send announcement to u...@sling.apache.org and annou...@apache.org
> --
>
> Key: SLING-6205
> URL: https://issues.apache.org/jira/browse/SLING-6205
> Project: Sling
>  Issue Type: Sub-task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-6201) Deploy Sling 9 docker image to Docker Hub

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved SLING-6201.

Resolution: Fixed

Deployed as apachesling/sling

> Deploy Sling 9 docker image to Docker Hub
> -
>
> Key: SLING-6201
> URL: https://issues.apache.org/jira/browse/SLING-6201
> Project: Sling
>  Issue Type: Sub-task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> Note - we should switch to the apache account instead of the apachesling one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6201) Deploy Sling 9 docker image to Docker Hub

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6201:


Well, using the infra-provided solution is a bit tougher than I expected. It 
relies on the automated builds docker hub feature, and according to INFRA-14123 
we need to point them to:

- a repository ( github.com/apache/sling )
- a tag
- a file location

The tag we should use is {{org.apache.sling.launchpad-9}}. But since we use SVN 
the tag only contains the launchpad/builder directory, and not launchpad/docker 
. So this is a no-go for now.

Will revisit for Sling 10. I think :-)

> Deploy Sling 9 docker image to Docker Hub
> -
>
> Key: SLING-6201
> URL: https://issues.apache.org/jira/browse/SLING-6201
> Project: Sling
>  Issue Type: Sub-task
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> Note - we should switch to the apache account instead of the apachesling one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-6951) Sling Resource Merger: hideChildren="*" incorrectly hides nested local children

[Konrad Windszus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated SLING-6951:
---
Summary: Sling Resource Merger: hideChildren="*" incorrectly hides nested 
local children  (was: Sling Resource Merger: hideChildren="*" only works 
correctly for first level of children)

> Sling Resource Merger: hideChildren="*" incorrectly hides nested local 
> children
> ---
>
> Key: SLING-6951
> URL: https://issues.apache.org/jira/browse/SLING-6951
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Resource Merger 1.3.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Resource Merger 1.3.4
>
>
> It seems that the changes to the wildcard handling of the ResourceMerger 
> being done in SLING-5468 only work correctly on the first level. Any deeper 
> nested local nodes are also not displayed when using 
> {{sling:hideChildren="*"}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-6951) Sling Resource Merger: hideChildren="*" only works correctly for first level of children

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6951:
--

 Summary: Sling Resource Merger: hideChildren="*" only works 
correctly for first level of children
 Key: SLING-6951
 URL: https://issues.apache.org/jira/browse/SLING-6951
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Resource Merger 1.3.2
Reporter: Konrad Windszus
Assignee: Konrad Windszus
 Fix For: Resource Merger 1.3.4


It seems that the changes to the wildcard handling of the ResourceMerger being 
done in SLING-5468 only work correctly on the first level. Any deeper nested 
local nodes are also not displayed when using {{sling:hideChildren="*"}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan edited comment on SLING-6422 at 6/13/17 9:52 AM:


[~bdelacretaz] I further verified that vault package manager also respects 
ordering. To verify I specified following aces
{code}






{code}
Since in above case restrictions and principal are same, package manager merged 
the privileges as follows
{code}



{code}


Then I tried with order reversed for restriction values as follows
{code}
 





{code}
In above case package manager did not merge ACEs because I think it also 
considers restrictions different. So, I suppose we should also consider 
restrictions with different ordering of values different. 
Also, the example date based restriction provider at \[0\] assumes ordered 
values
WDYT?

\[0\] 
http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



was (Author: nitin.nizhawan):
[~bdelacretaz] I further verified that vault package manager also respects 
ordering. To verify I specified following aces
{code}






{code}
Since in above case restrictions and principal are same, package manager merged 
the privileges as follows
{code}



{code}


Then I tried with order reversed for restriction values as follows
{code}
 





{code}
In above case package manager did not merge ACEs because I think it also 
considers restrictions different. So, I suppose we should also consider 
restrictions with different ordering of values different. WDYT?

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Nitin Nizhawan (JIRA)]

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

Nitin Nizhawan commented on SLING-6422:
---

[~bdelacretaz] I further verified that vault package manager also respects 
ordering. To verify I specified following aces
{code}






{code}
Since in above case restrictions and principal are same, package manager merged 
the privileges as follows
{code}



{code}


Then I tried with order reversed for restriction values as follows
{code}
 





{code}
In above case package manager did not merge ACEs because I think it also 
considers restrictions different. So, I suppose we should also consider 
restrictions with different ordering of values different. WDYT?

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-6422) Allow for specifying oak restrictions with repoinit

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6422:


IMO assuming that the arrays are ordered is fragile, considering that (unless I 
missed something) the spec doesn't mention any ordering. I would much prefer a 
comparison method that doesn't care about order, as problems with that would be 
costly to detect later.

> Allow for specifying oak restrictions with repoinit
> ---
>
> Key: SLING-6422
> URL: https://issues.apache.org/jira/browse/SLING-6422
> Project: Sling
>  Issue Type: New Feature
>  Components: Repoinit
>Reporter: Nitin Nizhawan
> Attachments: SLING6422ApplyRestrictionsV2.patch, 
> SLING6422ApplyRestrictionsV3.patch, 
> SLING6422_interpretparsedrestrictionclause.patch, SLING-6422.patch
>
>
> Allow for specifying oak restrictions with repoinit. Currently repoinit 
> allows one to ADD remove ACLs but there is no way to specify oak restrictions.
> http://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)