Re: Programmatically create a logger

2017-05-19 Thread Nicolas Peltier 
Did track that work here [0] and successfully created a configuration very 
similar to what SlingLogPanel creates, however, it seems that

org.osgi.service.cm.Configuration.update(dict) from sling pipes bundle does not 
trigger LoggerManagedServiceFactory.updated

The only difference I see from the configuration is the bundleLocation property.

Am I right to assume this will somehow not work because the event comes from a 
different bundle?  

[0] https://issues.apache.org/jira/browse/SLING-6861
> On 28 Apr 2017, at 15:57, Nicolas Peltier  wrote:
> 
> Hi,
> 
> For sling pipes, I’d like the possibility at each execution to create a log 
> file. 
> Instead of re-inventing the wheel, I figured out I could just create a 
> specific logger for the time being of the pipe execution, with configured log 
> level & so on. 
> 
> Is it possible at all?
> 
> Nicolas
>

[jira] [Created] (SLING-6867) Repoinit ACL handler should take aggregate privilege into account

2017-05-19 Thread Nitin Nizhawan (JIRA) 
Nitin Nizhawan created SLING-6867:
-

 Summary: Repoinit ACL handler should take aggregate privilege into 
account
 Key: SLING-6867
 URL: https://issues.apache.org/jira/browse/SLING-6867
 Project: Sling
  Issue Type: Bug
  Components: Repoinit
Affects Versions: Repoinit JCR 1.1.4
Reporter: Nitin Nizhawan


Repoinit ACLUtil "contains privileges" method does not take aggregation into 
account



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

2017-05-19 Thread angela (JIRA) 

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

angela edited comment on SLING-6422 at 5/19/17 2:18 PM:


[~nitin.nizhawan], oh... my bad... i didn't summit the comments :-( should be 
fixed now.


was (Author: anchela):
[~nitin.nizhawan], oh... my bad... i didn't summit the commits :-( should be 
fixed now.

> 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: 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.3.15#6346)

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

2017-05-19 Thread angela (JIRA) 

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

angela commented on SLING-6422:
---

[~nitin.nizhawan], oh... my bad... i didn't summit the commits :-( should be 
fixed now.

> 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: 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.3.15#6346)

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

2017-05-19 Thread Nitin Nizhawan (JIRA) 

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

Nitin Nizhawan commented on SLING-6422:
---

[~anchela] Thanks for your review. For some reason I am unable to see any 
comment at  https://github.com/apache/sling/pull/232
Probably I am looking at wrong place, could please check if this is where you 
have added comments.

CC: [~bdelacretaz] [~chetanm]
Thanks
Nitin

> 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: 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.3.15#6346)

[jira] [Updated] (SLING-6866) HTL doesn't allow to overwrite the context for data-sly-text

2017-05-19 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu updated SLING-6866:

Description: 
When using the following expression

{code:html}

{code}

the output is escaped.

  was:
For the following Sightly script
{code}

{code}
the generated Servlet looks like this
{code}
Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", 
"invalidelement", "unsafe"), "elementName");
if (RenderUtils.toBoolean(var_tagvar0)) {
out.write("<");
out.write(RenderUtils.toString(var_tagvar0));
}
if (!RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
if (RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
}
if (!RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
}
{code}

So the element name is XSS protected twice. First with 'unsafe' (which doesn't 
modify the given literal) and then with 'elementname', which removes the 
literal.
Therefore the generated HTML from the servlet is {{}} instead of 
{{}}

This contradicts the documentation at 
https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which says
{quote}
For security reasons, data-sly-element accepts only the following element names:
a abbr address article aside b bdi bdo blockquote br caption cite code col 
colgroup
data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 header 
i ins
kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong sub 
sup table tbody td tfoot th thead time tr u var wbr

To set other elements, XSS security must be turned off (@context='unsafe').
{quote}

The HTL spec only says
{quote}
The element name is automatically XSS-protected with the elementName context, 
which by the way doesn't allow elements like

[jira] [Updated] (SLING-6866) HTL doesn't allow to overwrite the context for data-sly-text

2017-05-19 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu updated SLING-6866:

Fix Version/s: (was: Scripting HTL Compiler 1.0.0)
   (was: Scripting HTL Engine 1.0.20)
   Scripting HTL Compiler 1.0.10

> HTL doesn't allow to overwrite the context for data-sly-text
> 
>
> Key: SLING-6866
> URL: https://issues.apache.org/jira/browse/SLING-6866
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.0.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.10
>
>
> For the following Sightly script
> {code}
> 
> {code}
> the generated Servlet looks like this
> {code}
> Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", 
> "invalidelement", "unsafe"), "elementName");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write("<");
> out.write(RenderUtils.toString(var_tagvar0));
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" }
> out.write(">");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" out.write(RenderUtils.toString(var_tagvar0));
> out.write(">");
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write("");
> }
> {code}
> So the element name is XSS protected twice. First with 'unsafe' (which 
> doesn't modify the given literal) and then with 'elementname', which removes 
> the literal.
> Therefore the generated HTML from the servlet is {{}} instead of 
> {{}}
> This contradicts the documentation at 
> https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which 
> says
> {quote}
> For security reasons, data-sly-element accepts only the following element 
> names:
> a abbr address article aside b bdi bdo blockquote br caption cite code col 
> colgroup
> data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 
> header i ins
> kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong 
> sub 
> sup table tbody td tfoot th thead time tr u var wbr
> To set other elements, XSS security must be turned off (@context='unsafe').
> {quote}
> The HTL spec only says
> {quote}
> The element name is automatically XSS-protected with the elementName context, 
> which by the way doesn't allow elements like

[jira] [Created] (SLING-6866) HTL doesn't allow to overwrite the context for data-sly-text

2017-05-19 Thread Radu Cotescu (JIRA) 
Radu Cotescu created SLING-6866:
---

 Summary: HTL doesn't allow to overwrite the context for 
data-sly-text
 Key: SLING-6866
 URL: https://issues.apache.org/jira/browse/SLING-6866
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Sightly Engine 1.0.18
Reporter: Konrad Windszus
Assignee: Radu Cotescu
 Fix For: Scripting HTL Engine 1.0.20, Scripting HTL Compiler 1.0.0


For the following Sightly script
{code}

{code}
the generated Servlet looks like this
{code}
Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", 
"invalidelement", "unsafe"), "elementName");
if (RenderUtils.toBoolean(var_tagvar0)) {
out.write("<");
out.write(RenderUtils.toString(var_tagvar0));
}
if (!RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
if (RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
}
if (!RenderUtils.toBoolean(var_tagvar0)) {
out.write("");
}
{code}

So the element name is XSS protected twice. First with 'unsafe' (which doesn't 
modify the given literal) and then with 'elementname', which removes the 
literal.
Therefore the generated HTML from the servlet is {{}} instead of 
{{}}

This contradicts the documentation at 
https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which says
{quote}
For security reasons, data-sly-element accepts only the following element names:
a abbr address article aside b bdi bdo blockquote br caption cite code col 
colgroup
data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 header 
i ins
kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong sub 
sup table tbody td tfoot th thead time tr u var wbr

To set other elements, XSS security must be turned off (@context='unsafe').
{quote}

The HTL spec only says
{quote}
The element name is automatically XSS-protected with the elementName context, 
which by the way doesn't allow elements like

[jira] [Updated] (SLING-6866) HTL doesn't allow to overwrite the context for data-sly-text

2017-05-19 Thread Radu Cotescu (JIRA) 

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

Radu Cotescu updated SLING-6866:

Affects Version/s: (was: Scripting Sightly Engine 1.0.18)
   Scripting HTL Compiler 1.0.0

> HTL doesn't allow to overwrite the context for data-sly-text
> 
>
> Key: SLING-6866
> URL: https://issues.apache.org/jira/browse/SLING-6866
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.0.0
>Reporter: Konrad Windszus
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.10
>
>
> For the following Sightly script
> {code}
> 
> {code}
> the generated Servlet looks like this
> {code}
> Object var_tagvar0 = renderContext.call("xss", renderContext.call("xss", 
> "invalidelement", "unsafe"), "elementName");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write("<");
> out.write(RenderUtils.toString(var_tagvar0));
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" }
> out.write(">");
> if (RenderUtils.toBoolean(var_tagvar0)) {
> out.write(" out.write(RenderUtils.toString(var_tagvar0));
> out.write(">");
> }
> if (!RenderUtils.toBoolean(var_tagvar0)) {
> out.write("");
> }
> {code}
> So the element name is XSS protected twice. First with 'unsafe' (which 
> doesn't modify the given literal) and then with 'elementname', which removes 
> the literal.
> Therefore the generated HTML from the servlet is {{}} instead of 
> {{}}
> This contradicts the documentation at 
> https://docs.adobe.com/docs/en/htl/docs/block-statements.html#element which 
> says
> {quote}
> For security reasons, data-sly-element accepts only the following element 
> names:
> a abbr address article aside b bdi bdo blockquote br caption cite code col 
> colgroup
> data dd del dfn div dl dt em figcaption figure footer h1 h2 h3 h4 h5 h6 
> header i ins
> kbd li main mark nav ol p pre q rp rt ruby s samp section small span strong 
> sub 
> sup table tbody td tfoot th thead time tr u var wbr
> To set other elements, XSS security must be turned off (@context='unsafe').
> {quote}
> The HTL spec only says
> {quote}
> The element name is automatically XSS-protected with the elementName context, 
> which by the way doesn't allow elements like

Re: svn commit: r1795540 - in /sling/trunk/bundles/scripting/jsp-taglib: pom.xml src/main/java/org/apache/sling/scripting/jsp/taglib/package-info.java

2017-05-19 Thread Radu Cotescu 
I might have hit send too early - could you please rollback your changes
from trunk?

On Fri, 19 May 2017 at 11:53 Radu Cotescu  wrote:

> Hi Dan,
>
> That's where the problem is - your Maven instance seems to be picking a
> different artifact version than what was officially released the last time:
> 2.2.6-53compat.
>
> Cheers,
> Radu
>
> On Thu, 18 May 2017 at 22:01 Daniel Klco  wrote:
>
>> Radu,
>>
>> Totally fair. When I roll back to r1795539, I see the following in the
>> baseline report:
>>
>> https://gist.github.com/klcodanr/43625af985e2524892c6994c20e8c50f
>>
>> Thanks,
>> Dan
>>
>> On Thu, May 18, 2017 at 12:31 PM, Radu Cotescu  wrote:
>>
>> > Hi Dan,
>> >
>> > Could you please post the report of the baseline plugin before your
>> commit?
>> >
>> > At r1795516 I have this:
>> >
>> > [INFO] Comparing bundle org.apache.sling.scripting.jsp.taglib version
>> > 2.2.7-SNAPSHOT to version 2.2.6
>> > [INFO]
>> > [INFO]   PACKAGE_NAME   DELTA
>> >  CUR_VERBASE_VER   REC_VERWARNINGS
>> > [INFO] = == ==
>> > == == == ==
>> > [INFO]   org.apache.sling.scripting.jsp.taglib  unchanged
>> >  2.2.0  2.2.0  2.2.0  -
>> > [INFO]
>> > 
>> > ---
>> > [INFO]   org.apache.sling.scripting.jsp.taglib.helpers  unchanged
>> >  2.2.0  2.2.0  2.2.0  -
>> > [INFO]
>> > 
>> > ---
>> > [INFO]   org.apache.sling.scripting.jsp.taglib.tei  unchanged
>> >  2.2.0  2.2.0  2.2.0  -
>> > [INFO]
>> > 
>> > ---
>> > [INFO] Baseline analysis complete, 0 error(s), 0 warning(s)
>> >
>> >
>> > After your commit I see:
>> >
>> > [INFO]   PACKAGE_NAME   DELTA
>> >  CUR_VERBASE_VER   REC_VERWARNINGS
>> > [INFO] = == ==
>> > == == == ==
>> > [INFO]   org.apache.sling.scripting.jsp.taglib  unchanged
>> >  2.3.0  2.2.0  2.2.0  Version has been increased but
>> analysis
>> > detected no changes
>> > [INFO]  - version 2.2.0
>> > [INFO]  + version 2.3.0
>> > [INFO]
>> > 
>> > ---
>> > [INFO]   org.apache.sling.scripting.jsp.taglib.helpers  unchanged
>> >  2.2.0  2.2.0  2.2.0  -
>> > [INFO]
>> > 
>> > ---
>> > [INFO]   org.apache.sling.scripting.jsp.taglib.tei  unchanged
>> >  2.2.0  2.2.0  2.2.0  -
>> > [INFO]
>> > 
>> > ---
>> > [WARNING] org.apache.sling.scripting.jsp.taglib: Excessive version
>> > increase; detected 2.3.0, suggested 2.2.0
>> > [WARNING] org.apache.sling.scripting.jsp.taglib: Version has been
>> > increased
>> > but analysis detected no changes; detected 2.3.0, suggested 2.2.0
>> > [INFO] Baseline analysis complete, 0 error(s), 2 warning(s)
>> >
>> >
>> > I'd really like us to avoid increasing API versions without a good
>> reason.
>> >
>> > Thanks,
>> > Radu
>> >
>> > On Thu, 18 May 2017 at 16:38  wrote:
>> >
>> > > Author: dklco
>> > > Date: Thu May 18 14:38:40 2017
>> > > New Revision: 1795540
>> > >
>> > > URL: http://svn.apache.org/viewvc?rev=1795540=rev
>> > > Log:
>> > > Fixing baseline issues about the versioning of JSP Taglibs
>> > >
>> > > Modified:
>> > > sling/trunk/bundles/scripting/jsp-taglib/pom.xml
>> > >
>> > > sling/trunk/bundles/scripting/jsp-taglib/src/main/java/org/
>> > apache/sling/scripting/jsp/taglib/package-info.java
>> > >
>> > > Modified: sling/trunk/bundles/scripting/jsp-taglib/pom.xml
>> > > URL:
>> > > http://svn.apache.org/viewvc/sling/trunk/bundles/scripting/
>> > jsp-taglib/pom.xml?rev=1795540=1795539=1795540=diff
>> > >
>> > > 
>> > ==
>> > > --- sling/trunk/bundles/scripting/jsp-taglib/pom.xml (original)
>> > > +++ sling/trunk/bundles/scripting/jsp-taglib/pom.xml Thu May 18
>> 14:38:40
>> > > 2017
>> > > @@ -20,7 +20,7 @@
>> > > 
>> > >
>> > > org.apache.sling.scripting.jsp.taglib
>> > > -   2.2.7-SNAPSHOT
>> > > +   2.3.0-SNAPSHOT
>> > > bundle
>> > >
>> > > Apache Sling JSP Tag Library
>> > >
>> > > Modified:
>> > > sling/trunk/bundles/scripting/jsp-taglib/src/main/java/org/
>> >

Re: svn commit: r1795540 - in /sling/trunk/bundles/scripting/jsp-taglib: pom.xml src/main/java/org/apache/sling/scripting/jsp/taglib/package-info.java

2017-05-19 Thread Radu Cotescu 
Hi Dan,

That's where the problem is - your Maven instance seems to be picking a
different artifact version than what was officially released the last time:
2.2.6-53compat.

Cheers,
Radu

On Thu, 18 May 2017 at 22:01 Daniel Klco  wrote:

> Radu,
>
> Totally fair. When I roll back to r1795539, I see the following in the
> baseline report:
>
> https://gist.github.com/klcodanr/43625af985e2524892c6994c20e8c50f
>
> Thanks,
> Dan
>
> On Thu, May 18, 2017 at 12:31 PM, Radu Cotescu  wrote:
>
> > Hi Dan,
> >
> > Could you please post the report of the baseline plugin before your
> commit?
> >
> > At r1795516 I have this:
> >
> > [INFO] Comparing bundle org.apache.sling.scripting.jsp.taglib version
> > 2.2.7-SNAPSHOT to version 2.2.6
> > [INFO]
> > [INFO]   PACKAGE_NAME   DELTA
> >  CUR_VERBASE_VER   REC_VERWARNINGS
> > [INFO] = == ==
> > == == == ==
> > [INFO]   org.apache.sling.scripting.jsp.taglib  unchanged
> >  2.2.0  2.2.0  2.2.0  -
> > [INFO]
> > 
> > ---
> > [INFO]   org.apache.sling.scripting.jsp.taglib.helpers  unchanged
> >  2.2.0  2.2.0  2.2.0  -
> > [INFO]
> > 
> > ---
> > [INFO]   org.apache.sling.scripting.jsp.taglib.tei  unchanged
> >  2.2.0  2.2.0  2.2.0  -
> > [INFO]
> > 
> > ---
> > [INFO] Baseline analysis complete, 0 error(s), 0 warning(s)
> >
> >
> > After your commit I see:
> >
> > [INFO]   PACKAGE_NAME   DELTA
> >  CUR_VERBASE_VER   REC_VERWARNINGS
> > [INFO] = == ==
> > == == == ==
> > [INFO]   org.apache.sling.scripting.jsp.taglib  unchanged
> >  2.3.0  2.2.0  2.2.0  Version has been increased but analysis
> > detected no changes
> > [INFO]  - version 2.2.0
> > [INFO]  + version 2.3.0
> > [INFO]
> > 
> > ---
> > [INFO]   org.apache.sling.scripting.jsp.taglib.helpers  unchanged
> >  2.2.0  2.2.0  2.2.0  -
> > [INFO]
> > 
> > ---
> > [INFO]   org.apache.sling.scripting.jsp.taglib.tei  unchanged
> >  2.2.0  2.2.0  2.2.0  -
> > [INFO]
> > 
> > ---
> > [WARNING] org.apache.sling.scripting.jsp.taglib: Excessive version
> > increase; detected 2.3.0, suggested 2.2.0
> > [WARNING] org.apache.sling.scripting.jsp.taglib: Version has been
> > increased
> > but analysis detected no changes; detected 2.3.0, suggested 2.2.0
> > [INFO] Baseline analysis complete, 0 error(s), 2 warning(s)
> >
> >
> > I'd really like us to avoid increasing API versions without a good
> reason.
> >
> > Thanks,
> > Radu
> >
> > On Thu, 18 May 2017 at 16:38  wrote:
> >
> > > Author: dklco
> > > Date: Thu May 18 14:38:40 2017
> > > New Revision: 1795540
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1795540=rev
> > > Log:
> > > Fixing baseline issues about the versioning of JSP Taglibs
> > >
> > > Modified:
> > > sling/trunk/bundles/scripting/jsp-taglib/pom.xml
> > >
> > > sling/trunk/bundles/scripting/jsp-taglib/src/main/java/org/
> > apache/sling/scripting/jsp/taglib/package-info.java
> > >
> > > Modified: sling/trunk/bundles/scripting/jsp-taglib/pom.xml
> > > URL:
> > > http://svn.apache.org/viewvc/sling/trunk/bundles/scripting/
> > jsp-taglib/pom.xml?rev=1795540=1795539=1795540=diff
> > >
> > > 
> > ==
> > > --- sling/trunk/bundles/scripting/jsp-taglib/pom.xml (original)
> > > +++ sling/trunk/bundles/scripting/jsp-taglib/pom.xml Thu May 18
> 14:38:40
> > > 2017
> > > @@ -20,7 +20,7 @@
> > > 
> > >
> > > org.apache.sling.scripting.jsp.taglib
> > > -   2.2.7-SNAPSHOT
> > > +   2.3.0-SNAPSHOT
> > > bundle
> > >
> > > Apache Sling JSP Tag Library
> > >
> > > Modified:
> > > sling/trunk/bundles/scripting/jsp-taglib/src/main/java/org/
> > apache/sling/scripting/jsp/taglib/package-info.java
> > > URL:
> > > http://svn.apache.org/viewvc/sling/trunk/bundles/scripting/
> > jsp-taglib/src/main/java/org/apache/sling/scripting/jsp/
> > taglib/package-info.java?rev=1795540=1795539=1795540=diff
> > >
> > > 
> >

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

2017-05-19 Thread angela (JIRA) 

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

angela commented on SLING-6422:
---

[~nitin.nizhawan], i commented on the pull request on github. the patch looks 
good in general and apart from 2 bugs (one not even related to your changes) i 
just found minor things that need to be addressed (imo).

> 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: 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.3.15#6346)

[jira] [Updated] (SLING-6865) Default Config sling/xss/config.xml and XSSFilterImpl is not the same

2017-05-19 Thread Jan Stettler (JIRA) 

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

Jan Stettler updated SLING-6865:

Description: 
There is a different default config for XSSFilterImpl .href 
In XSSFilter.java the pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing 
{code}(\\){code}

Also the SLING-INF.content/config.xml has the wrong Pattern.

Can you fix this?

Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
com.adobe.granite.xssprotection-5.5.72

  was:
There is a different default config for XSSFilterImpl .href 
In XSSFilter.java the pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Also the SLING-INF.content/config.xml has the wrong Pattern.

Can you fix this?

Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
com.adobe.granite.xssprotection-5.5.72


> Default Config sling/xss/config.xml and XSSFilterImpl is not the same
> -
>
> Key: SLING-6865
> URL: https://issues.apache.org/jira/browse/SLING-6865
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Reporter: Jan Stettler
>Priority: Critical
>
> There is a different default config for XSSFilterImpl .href 
> In XSSFilter.java the pattern looks like
> {code}
> (\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
> {code}
> in the /libs/sling/xss/config.xml itself it looks like
> {code}
> (\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
> {code}
> In the config file there is a missing 
> {code}(\\){code}
> Also the SLING-INF.content/config.xml has the wrong Pattern.
> Can you fix this?
> Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
> com.adobe.granite.xssprotection-5.5.72



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6865) Default Config sling/xss/config.xml and XSSFilterImpl is not the same

2017-05-19 Thread Jan Stettler (JIRA) 

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

Jan Stettler updated SLING-6865:

Description: 
There is a different default config for XSSFilterImpl .href 
In XSSFilter.java the pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Also the SLING-INF.content/config.xml has the wrong Pattern.

Can you fix this?

Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
com.adobe.granite.xssprotection-5.5.72

  was:
There is a different default config for XSSFilterImpl .href 
In XSSFilter the Pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Also the SLING-INF.content/config.xml has the wrong Pattern.

Can you fix this?

Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
com.adobe.granite.xssprotection-5.5.72


> Default Config sling/xss/config.xml and XSSFilterImpl is not the same
> -
>
> Key: SLING-6865
> URL: https://issues.apache.org/jira/browse/SLING-6865
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Reporter: Jan Stettler
>Priority: Critical
>
> There is a different default config for XSSFilterImpl .href 
> In XSSFilter.java the pattern looks like
> {code}
> (\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
> {code}
> in the /libs/sling/xss/config.xml itself it looks like
> {code}
> (\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
> {code}
> In the config file there is a missing (\\)
> Also the SLING-INF.content/config.xml has the wrong Pattern.
> Can you fix this?
> Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
> com.adobe.granite.xssprotection-5.5.72



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6865) Default Config sling/xss/config.xml and XSSFilterImpl is not the same

2017-05-19 Thread Jan Stettler (JIRA) 

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

Jan Stettler updated SLING-6865:

Description: 
There is a different default config for XSSFilterImpl .href 
In XSSFilter the Pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Also the SLING-INF.content/config.xml has the wrong Pattern.

Can you fix this?

Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
com.adobe.granite.xssprotection-5.5.72

  was:
There is a different default config for XSSFilterImpl .href 
In XSSFilter the Pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Can you fix this?


> Default Config sling/xss/config.xml and XSSFilterImpl is not the same
> -
>
> Key: SLING-6865
> URL: https://issues.apache.org/jira/browse/SLING-6865
> Project: Sling
>  Issue Type: Bug
>  Components: XSS Protection API
>Reporter: Jan Stettler
>Priority: Critical
>
> There is a different default config for XSSFilterImpl .href 
> In XSSFilter the Pattern looks like
> {code}
> (\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
> {code}
> in the /libs/sling/xss/config.xml itself it looks like
> {code}
> (\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
> {code}
> In the config file there is a missing (\\)
> Also the SLING-INF.content/config.xml has the wrong Pattern.
> Can you fix this?
> Problem is in package: com.adobe.granite.xssprotection-5.5.68 and 
> com.adobe.granite.xssprotection-5.5.72



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6865) Default Config sling/xss/config.xml and XSSFilterImpl is not the same

2017-05-19 Thread Jan Stettler (JIRA) 
Jan Stettler created SLING-6865:
---

 Summary: Default Config sling/xss/config.xml and XSSFilterImpl is 
not the same
 Key: SLING-6865
 URL: https://issues.apache.org/jira/browse/SLING-6865
 Project: Sling
  Issue Type: Bug
  Components: XSS Protection API
Reporter: Jan Stettler
Priority: Critical


There is a different default config for XSSFilterImpl .href 
In XSSFilter the Pattern looks like
{code}
(\\s)*((ht|f)tp(s?)://|mailto:)[\\p{L}\\p{N}]+[\\p{L}\\p{N}\\p{Zs}\\.\\#@\\$%\\+&;:\\-_~,\\?=/!\\*\\(\\)]*(\\s)*"
{code}

in the /libs/sling/xss/config.xml itself it looks like
{code}
(\s)*((ht|f)tp(s?)://|mailto:)[\p{L}\p{N}]+[\p{L}\p{N}\p{Zs}\.\#@\$%\+;:\-_~,\?=/!\*\(\)]*(\s)*
{code}

In the config file there is a missing (\\)

Can you fix this?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)