[jira] [Commented] (SLING-7975) Add a Java API for ordering resources

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7975:


Please be aware that {{AbstractPostOperation}} is deprecated (SLING-6722) for 
the reason that it  binds to the JCR API. Since the resource provider SPI does 
not support an explicit reorder operation 
([https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/spi/resource/provider/ResourceProvider.java)]
 exposing such a method must either be a NOOP or throw an exception for all 
ResourceProviders but the JcrResourceProvider.

> Add a Java API for ordering resources
> -
>
> Key: SLING-7975
> URL: https://issues.apache.org/jira/browse/SLING-7975
> Project: Sling
>  Issue Type: New Feature
>  Components: API
>Reporter: Jean-Christophe Kautzmann
>Priority: Major
>
> Sling should provide an API (e.g. in Resource, ResourceResolver or 
> ResourceUtil) to order resources, similar to what the JCR API provides:
> [https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Node.html#orderBefore(java.lang.String,%20java.lang.String])
>  
> This would help avoid having to use the JCR API.
>  
> The implementation is already available at:
> [https://github.com/apache/sling-old-svn-mirror/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java#L411]
>  
> It is only a matter of exposing it as part of the Sling API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [sling:resourceType] protected execution

[Jason E Bailey]

On Wed, Oct 3, 2018, at 7:57 AM, Radu Cotescu wrote:

> Servlets do create Sling resources, but that’s not applicable to scripts 
> deployed in the search paths. 

Could you clarify that a bit for me. I'm under the impression that in Sling 
everything is a resource, when does it not create a resource?

Thanks
-Jason

[jira] [Commented] (SLING-7976) Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[Simone Tripodi (JIRA)]

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

Simone Tripodi commented on SLING-7976:
---

Aww thanks a lot [~bosschaert], glad to read you liked it! :)

> Track the slingfeature-maven-plugin:analyse-features activity and fail when 
> the whole scan detects errors
> -
>
> Key: SLING-7976
> URL: https://issues.apache.org/jira/browse/SLING-7976
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> Currently the {{AnalyseFeaturesMojo}} only reports the {{Analyzer}} activity 
> and never fails.
> I am going to submit a PR with a proposal of making the Mojo track errors and 
> fail once the scan is complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: How to manage repoinit language + implementation evolutions?

[Eric Norman]

I'm with Jörg, the old syntax was fine.  The bad behavior seems to be just
a bug to me that should just be fixed.   Adding more complex choices seems
unnecessary.

Regards,
Eric

On Wed, Oct 3, 2018, 9:58 AM Dominik Süß  wrote:

> Hi Jörg,
>
> As you can imagine I disagree as users might have used the statement
> already to delete service users and depend on that behavior.
>
> Replacing the commands by new variations with refined behavior sounds to me
> like a fair compromise. We could even deprecate the old syntax and spawn a
> warning that usage of those commands is discouraged due to being not
> descriptive enough of their impact.
>
> My 2 cents
> Dominik
>
> Jörg Hoh  schrieb am Mi. 3. Okt. 2018 um
> 13:24:
>
> > Hi,
> >
> > Am Di., 2. Okt. 2018 um 07:46 Uhr schrieb Karl Pauls <
> karlpa...@gmail.com
> > >:
> >
> > > Can’t we stay BC and just introduce a new command that has the new
> > behavior
> > > and keep the old one as is?
> > >
> > > Something like:
> > >
> > > DELETE REAL USER
> > >
> > > or similar would be consistent with the service user delete at least.
> > >
> >
> > So you would add some additional commands to the language, which finally
> do
> > what the original version promised to do?
> >
> > * DELETE USER foo -> removes both real and service users (as today)
> > * DELETE SERVICE USER foo -> removes both real and service users (as
> today)
> > * DELETE REAL USER foo -> would delete only a real user?
> > * DELETE REAL SERVICE USER foo -> would delete only a service user?
> >
> > Looks absurd to me. I agree the backward-compatibility is highly
> important,
> > but here it prevents to fix bugs. Also I haven't found any documentation
> > which clearly explains the operations in detail, so I had to guess from
> the
> > repoinit examples what the operations are supposed to do. So the current
> > implementation does not contradict the documentation or specification
> > because there is none. But it contradicts the expectation I got from
> > reading the command. If there is a "DELETE USER" and a "DELETE SERVICE
> > USER" command, there must be different implementation behind it
> (otherwise
> > there would be only 1 command), and the obvious difference is the the
> > "DELETE SERVICE USER" deletes a service user.
> >
> > I would also assume that any user of repoinit, who started based on the
> > existing documentation has the impression as I have and used the commands
> > in the same way; but I would question even that, because then this flaw
> in
> > the implementation would have been found much earlier.
> >
> > So my proposal is to fix the bug, change the implementation in the
> > incompatible way (maybe add some log messages for the cases where the old
> > implementation would done the wrong thing) and document it properly. And
> > that's it.
> >
> >
> > --
> > Cheers,
> > Jörg Hoh,
> >
> > http://cqdump.wordpress.com
> > Twitter: @joerghoh
> >
>

Re: [sling:resourceType] protected execution

[Eric Norman]

Is it the resource type that needs protection?  Or the script/servlet that
is handling a specific method+selector+extension for the resource type?

I generally prefer to have all my servlets get called regardless of whether
the user has rights to do that action so any invalid requests can be
handled in a consistent manner and I can block passing off the handling to
other unknown handlers.  A servlet (or filter) can easily do access checks
in java code at the beginning of the handler and send the appropriate error
response if the user doesn't have the right privileges.  And we already
have the OptingServlet interface for servlets which may choose to not
handle all requests for which they would be selected if you want the
handling to fall through.

For my own projects, I used to do access checking in each "esp" script, but
after migrating to from "esp" to "htl" scripts some refactoring was
required and this is what I came up with:
1. To handle POST requests, each servlet does it's own access checking in
java code to ensure the right privileges are granted before any processing
happens.

2. To handle GET requests I utilize two generic filters whose configuration
is supplied by other multiple "config" OSGi services:
  a) SelectorWhitelistFilter - block access to any unexpected selectors.  A
SelectorWhitelist configuration OSGi service is registered for each
resource type to declare which selectors are allowed for each resource type.
  b) BlockNotAuthorizedFilter - for selectors that get past #1, check
permissions and block access for users who don't have the required
privileges.  A NotAuthorized OSGi service is registered for each family of
scripts to do the appropriate checks.

The code was pretty simple and I could probably share it if anyone is
interested.

Regards,
-Eric

On Wed, Oct 3, 2018 at 4:57 AM Radu Cotescu  wrote:

> Hi,
>
> A recent thread [0] presented the idea of adding a more generic mechanism
> to restrict the execution of certain servlets, based on capabilities;
> however, we didn’t reach any consensus.
>
> Several suggestions were presented, based on providing additional
> ResourceProviders or implementing ResourceAccessGates, but we never got
> anywhere and I think that neither of those two approaches are complete.
>
> Servlets do create Sling resources, but that’s not applicable to scripts
> deployed in the search paths. IMO, we’d need one central place where we
> evaluate resource type execution permission and this should happen in the
> org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t
> think we’d need a new external API for now, hence why I’d limit the
> implementation to something very simple:
>
> 1. Create a /system/permissions protected resource (restrict access based
> on ACLs)
> 2. Define permissions that can be added: e.g.
> /system/permissions/sling:resourceType
> 3. Define resource types that need to be protected: e.g.
> /system/permissions/sling:resourceType/org/acme/weather
> 4. Define ACLs that govern who can execute a certain resource type: e.g.
> /system/permissions/sling:resourceType/org/acme/weather/rep:policy where
> we’d whitelist (allow) reading (jcr:read) for certain principals
> 5. In the ServletResolver check the current resource type, find its
> mapping in  /system/permissions/sling:resourceType and see if the current
> user can read it (Resource API)
> 5.1. If the user can read it, continue with the regular flow of servlet
> resolution - the user is allowed to execute the current resource type
> 5.2. If not, there are two options:
> 5.2.1. the resource exists (check with a higher privileged user),
> which means that the current user should not be allowed to execute
> whatever’s mapped behind the resource type
> 5.2.2. the resource doesn’t exist, which means that the resource
> type is not protected, so we continue with the normal servlet resolution
> phase
>
> In this way we’d delegate all the checks to the ResourceProviders. The
> persistence mechanism that Sling uses would define what and how can be
> accessed, given that Sling has no other way to enforce Resource access
> control - the ResourceAccessGate API seems incomplete. It’s important to
> note that this implementation would be based though on content structures,
> which have to be stable. As soon as we have to change the structure we
> introduce breaking changes, which will not be easy to handle.
>
> Thoughts?
>
> Thanks,
> Radu
>
> [0] -
> https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E

[jira] [Resolved] (SLING-7976) Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[David Bosschaert (JIRA)]

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

David Bosschaert resolved SLING-7976.
-
Resolution: Fixed

Thanks [~simone.tripodi]! I have merged your pull request.

> Track the slingfeature-maven-plugin:analyse-features activity and fail when 
> the whole scan detects errors
> -
>
> Key: SLING-7976
> URL: https://issues.apache.org/jira/browse/SLING-7976
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> Currently the {{AnalyseFeaturesMojo}} only reports the {{Analyzer}} activity 
> and never fails.
> I am going to submit a PR with a proposal of making the Mojo track errors and 
> fail once the scan is complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7976) Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[ASF GitHub Bot (JIRA)]

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

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

bosschaert closed pull request #1: SLING-7976 - Track the 
slingfeature-maven-plugin:analyse-features activity and fail when the whole 
scan detects errors
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Track the slingfeature-maven-plugin:analyse-features activity and fail when 
> the whole scan detects errors
> -
>
> Key: SLING-7976
> URL: https://issues.apache.org/jira/browse/SLING-7976
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> Currently the {{AnalyseFeaturesMojo}} only reports the {{Analyzer}} activity 
> and never fails.
> I am going to submit a PR with a proposal of making the Mojo track errors and 
> fail once the scan is complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] bosschaert closed pull request #1: SLING-7976 - Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[GitBox]

bosschaert closed pull request #1: SLING-7976 - Track the 
slingfeature-maven-plugin:analyse-features activity and fail when the whole 
scan detects errors
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: How to manage repoinit language + implementation evolutions?

[Dominik Süß]

Hi Jörg,

As you can imagine I disagree as users might have used the statement
already to delete service users and depend on that behavior.

Replacing the commands by new variations with refined behavior sounds to me
like a fair compromise. We could even deprecate the old syntax and spawn a
warning that usage of those commands is discouraged due to being not
descriptive enough of their impact.

My 2 cents
Dominik

Jörg Hoh  schrieb am Mi. 3. Okt. 2018 um
13:24:

> Hi,
>
> Am Di., 2. Okt. 2018 um 07:46 Uhr schrieb Karl Pauls  >:
>
> > Can’t we stay BC and just introduce a new command that has the new
> behavior
> > and keep the old one as is?
> >
> > Something like:
> >
> > DELETE REAL USER
> >
> > or similar would be consistent with the service user delete at least.
> >
>
> So you would add some additional commands to the language, which finally do
> what the original version promised to do?
>
> * DELETE USER foo -> removes both real and service users (as today)
> * DELETE SERVICE USER foo -> removes both real and service users (as today)
> * DELETE REAL USER foo -> would delete only a real user?
> * DELETE REAL SERVICE USER foo -> would delete only a service user?
>
> Looks absurd to me. I agree the backward-compatibility is highly important,
> but here it prevents to fix bugs. Also I haven't found any documentation
> which clearly explains the operations in detail, so I had to guess from the
> repoinit examples what the operations are supposed to do. So the current
> implementation does not contradict the documentation or specification
> because there is none. But it contradicts the expectation I got from
> reading the command. If there is a "DELETE USER" and a "DELETE SERVICE
> USER" command, there must be different implementation behind it (otherwise
> there would be only 1 command), and the obvious difference is the the
> "DELETE SERVICE USER" deletes a service user.
>
> I would also assume that any user of repoinit, who started based on the
> existing documentation has the impression as I have and used the commands
> in the same way; but I would question even that, because then this flaw in
> the implementation would have been found much earlier.
>
> So my proposal is to fix the bug, change the implementation in the
> incompatible way (maybe add some log messages for the cases where the old
> implementation would done the wrong thing) and document it properly. And
> that's it.
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
>

[jira] [Resolved] (SLING-7977) When merging features artifacts should keep an association with their originating feature

[David Bosschaert (JIRA)]

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

David Bosschaert resolved SLING-7977.
-
   Resolution: Fixed
Fix Version/s: Feature Model 0.1.4

Fixed with 
https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-feature.git;a=commitdiff;h=fdd31ea3855c0c5e6081150892b03ec5b98848c9

> When merging features artifacts should keep an association with their 
> originating feature
> -
>
> Key: SLING-7977
> URL: https://issues.apache.org/jira/browse/SLING-7977
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: Feature Model 0.1.2
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
> Fix For: Feature Model 0.1.4
>
>
> When features are merged, artifacts such as bundles are merged into a single 
> feature. For certain operations, for example API whitelisting it must be 
> possible to know what the original feature was that contained the artifact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7977) When merging features artifacts should keep an association with their originating feature

[David Bosschaert (JIRA)]

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

David Bosschaert updated SLING-7977:

Affects Version/s: Feature Model 0.1.2

> When merging features artifacts should keep an association with their 
> originating feature
> -
>
> Key: SLING-7977
> URL: https://issues.apache.org/jira/browse/SLING-7977
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: Feature Model 0.1.2
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
>
> When features are merged, artifacts such as bundles are merged into a single 
> feature. For certain operations, for example API whitelisting it must be 
> possible to know what the original feature was that contained the artifact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SLING-7977) When merging features artifacts should keep an association with their originating feature

[David Bosschaert (JIRA)]

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

David Bosschaert updated SLING-7977:

Component/s: Feature Model

> When merging features artifacts should keep an association with their 
> originating feature
> -
>
> Key: SLING-7977
> URL: https://issues.apache.org/jira/browse/SLING-7977
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: Feature Model 0.1.2
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>Priority: Major
>
> When features are merged, artifacts such as bundles are merged into a single 
> feature. For certain operations, for example API whitelisting it must be 
> possible to know what the original feature was that contained the artifact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-7977) When merging features artifacts should keep an association with their originating feature

[David Bosschaert (JIRA)]

David Bosschaert created SLING-7977:
---

 Summary: When merging features artifacts should keep an 
association with their originating feature
 Key: SLING-7977
 URL: https://issues.apache.org/jira/browse/SLING-7977
 Project: Sling
  Issue Type: New Feature
Reporter: David Bosschaert
Assignee: David Bosschaert


When features are merged, artifacts such as bundles are merged into a single 
feature. For certain operations, for example API whitelisting it must be 
possible to know what the original feature was that contained the artifact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-7976) Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[ASF GitHub Bot (JIRA)]

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

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

simonetripodi opened a new pull request #1: SLING-7976 - Track the 
slingfeature-maven-plugin:analyse-features activity and fail when the whole 
scan detects errors
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/1
 
 
   initial checkin


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Track the slingfeature-maven-plugin:analyse-features activity and fail when 
> the whole scan detects errors
> -
>
> Key: SLING-7976
> URL: https://issues.apache.org/jira/browse/SLING-7976
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Simone Tripodi
>Assignee: David Bosschaert
>Priority: Major
>
> Currently the {{AnalyseFeaturesMojo}} only reports the {{Analyzer}} activity 
> and never fails.
> I am going to submit a PR with a proposal of making the Mojo track errors and 
> fail once the scan is complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] simonetripodi opened a new pull request #1: SLING-7976 - Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[GitBox]

simonetripodi opened a new pull request #1: SLING-7976 - Track the 
slingfeature-maven-plugin:analyse-features activity and fail when the whole 
scan detects errors
URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/1
 
 
   initial checkin


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (SLING-7976) Track the slingfeature-maven-plugin:analyse-features activity and fail when the whole scan detects errors

[Simone Tripodi (JIRA)]

Simone Tripodi created SLING-7976:
-

 Summary: Track the slingfeature-maven-plugin:analyse-features 
activity and fail when the whole scan detects errors
 Key: SLING-7976
 URL: https://issues.apache.org/jira/browse/SLING-7976
 Project: Sling
  Issue Type: Improvement
  Components: Feature Model, Maven Plugins and Archetypes
Reporter: Simone Tripodi
Assignee: David Bosschaert


Currently the {{AnalyseFeaturesMojo}} only reports the {{Analyzer}} activity 
and never fails.

I am going to submit a PR with a proposal of making the Mojo track errors and 
fail once the scan is complete.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Sling Type System: started a wiki page for concepts, ideas, motivation

[Jason E Bailey]

Let me see how close I am to your thought process.

A resource can have a sling:resourceType which defines the process which 
processes the resource. That is the default process, however you can apply 
other resourceTypes to that resource so it's  processed differently based on 
your need. 

To me that makes it more like an OO interface. 

Right now, you can apply any resourceType to any resource and it will attempt 
to handle it. Even if the values on the resource that the resourceType requires 
aren't there.

By assigning types to the resourceType  you can define required/optional fields 
and the types of actions that can occur on that resource. 

This will then give you the ability to do the following
1. generate meta data about the resource for use with a UI
2. potentially used as a field validation if someone attempts to create a 
resource type without the proper fields
3. Will generate an error if they use something like sling:include to override 
the default resourceType and the new resourceType requires properties that the 
resource doesn't have.

How am I doing?

- Jason

On Tue, Oct 2, 2018, at 10:15 AM, Bertrand Delacretaz wrote:
> Hi Jason,
> 
> thanks for your feedback!
> 
> On Tue, Oct 2, 2018 at 3:48 PM Jason E Bailey  wrote:
> > ...To restate. Given a resource, you should be able to define what 
> > properties that resource can contain and what child resources it can be the 
> > parent of...
> 
> Yes, among other things including some that we might discover along the way.
> 
> > ...1. There's some things that are implicit. For example, stating that a 
> > resource can be a parent of a resource would imply
> > that you could perform the action to create the child resource
> 
> Absolutely, which means we can generate hyperlinks for such operations
> automatically.
> 
> >... We're still a REST platform, do we need to have actions that are 
> >different then the standard REST methods? Would we have something 
> >different?...
> 
> I think actions can be more specific, at least in terms of their
> link:rel values.
> 
> A hyperlink can say
> 
>   link:rel=sling.create.imagefolder, method=POST, path=./images
> 
> as basically it, along with the Sling Type System (STS) typedef, needs
> to contain enough information to generate an HTML form when generating
> a UI.
> 
> maybe...just thinking outloud, but basically an action can have a more
> specific name than POST to clarify what it does exactly.
> 
> > ...Looking at the code, I get confused between a type for a resource and a 
> > sling:resourceType. I believe these are different things
> 
> I think it's fair to describe the code as a hack created when those
> ideas where still emerging ;-)
> 
> My point of view is that a resourceType points to an STS typedef,
> which conceptually points to rendering scripts or servlets.
> 
> That's conceptually...in practice I think we can keep the current
> script resolution mechanism, but the STS typedef might validate
> operations before passing them on.
> 
> Does that address your concerns?
> 
> That's all still vague for now anyway, needs to be defined more
> clearly and proven with prototypes.
> 
> -Bertrand

Re: [jenkins] has anybody contacted INFRA?

[Radu Cotescu]

https://issues.apache.org/jira/browse/INFRA-17089 

https://issues.apache.org/jira/browse/INFRA-17090 



> On 3 Oct 2018, at 12:16, Robert Munteanu  wrote:
> 
> On Wed, 2018-10-03 at 12:03 +0200, Bertrand Delacretaz wrote:
>> On Wed, Oct 3, 2018 at 11:30 AM Radu Cotescu  wrote:
>>> https://builds.apache.org/view/S-Z/view/Sling-Dashboard/
>> 
>> Not me, and what I see is a 401 response when deploying artifacts,
>> see below.
>> 
>> Are we missing deploy credentials somewhere maybe? I don't know off
>> the top of my head how that's setup.
> 
> Not me either. Credentials are automatically inherited by jobs, I think
> we should contact INFRA and ask them about this.
> 
> Robert
> 

[sling:resourceType] protected execution

[Radu Cotescu]

Hi,

A recent thread [0] presented the idea of adding a more generic mechanism to 
restrict the execution of certain servlets, based on capabilities; however, we 
didn’t reach any consensus.

Several suggestions were presented, based on providing additional 
ResourceProviders or implementing ResourceAccessGates, but we never got 
anywhere and I think that neither of those two approaches are complete.

Servlets do create Sling resources, but that’s not applicable to scripts 
deployed in the search paths. IMO, we’d need one central place where we 
evaluate resource type execution permission and this should happen in the 
org.apache.sling.servlets.resolver.internal.SlingServletResolver. I don’t think 
we’d need a new external API for now, hence why I’d limit the implementation to 
something very simple:

1. Create a /system/permissions protected resource (restrict access based on 
ACLs)
2. Define permissions that can be added: e.g. 
/system/permissions/sling:resourceType
3. Define resource types that need to be protected: e.g. 
/system/permissions/sling:resourceType/org/acme/weather
4. Define ACLs that govern who can execute a certain resource type: e.g. 
/system/permissions/sling:resourceType/org/acme/weather/rep:policy where we’d 
whitelist (allow) reading (jcr:read) for certain principals
5. In the ServletResolver check the current resource type, find its mapping in  
/system/permissions/sling:resourceType and see if the current user can read it 
(Resource API)
5.1. If the user can read it, continue with the regular flow of servlet 
resolution - the user is allowed to execute the current resource type
5.2. If not, there are two options:
5.2.1. the resource exists (check with a higher privileged user), which 
means that the current user should not be allowed to execute whatever’s mapped 
behind the resource type
5.2.2. the resource doesn’t exist, which means that the resource type 
is not protected, so we continue with the normal servlet resolution phase

In this way we’d delegate all the checks to the ResourceProviders. The 
persistence mechanism that Sling uses would define what and how can be 
accessed, given that Sling has no other way to enforce Resource access control 
- the ResourceAccessGate API seems incomplete. It’s important to note that this 
implementation would be based though on content structures, which have to be 
stable. As soon as we have to change the structure we introduce breaking 
changes, which will not be easy to handle.

Thoughts?

Thanks,
Radu

[0] - 
https://lists.apache.org/thread.html/a64ea3776e0c4dc6dbf4ca66739fa9ad8c5d7f02d51a2547b7c18ef3@%3Cdev.sling.apache.org%3E

[jira] [Created] (SLING-7975) Add a Java API for ordering resources

[Jean-Christophe Kautzmann (JIRA)]

Jean-Christophe Kautzmann created SLING-7975:


 Summary: Add a Java API for ordering resources
 Key: SLING-7975
 URL: https://issues.apache.org/jira/browse/SLING-7975
 Project: Sling
  Issue Type: New Feature
  Components: API
Reporter: Jean-Christophe Kautzmann


Sling should provide an API (e.g. in Resource, ResourceResolver or 
ResourceUtil) to order resources, similar to what the JCR API provides:
[https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Node.html#orderBefore(java.lang.String,%20java.lang.String])
 
This would help avoid having to use the JCR API.
 
The implementation is already available at:
[https://github.com/apache/sling-old-svn-mirror/blob/trunk/bundles/servlets/post/src/main/java/org/apache/sling/servlets/post/AbstractPostOperation.java#L411]
 
It is only a matter of exposing it as part of the Sling API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: How to manage repoinit language + implementation evolutions?

[Jörg Hoh]

Hi,

Am Di., 2. Okt. 2018 um 07:46 Uhr schrieb Karl Pauls :

> Can’t we stay BC and just introduce a new command that has the new behavior
> and keep the old one as is?
>
> Something like:
>
> DELETE REAL USER
>
> or similar would be consistent with the service user delete at least.
>

So you would add some additional commands to the language, which finally do
what the original version promised to do?

* DELETE USER foo -> removes both real and service users (as today)
* DELETE SERVICE USER foo -> removes both real and service users (as today)
* DELETE REAL USER foo -> would delete only a real user?
* DELETE REAL SERVICE USER foo -> would delete only a service user?

Looks absurd to me. I agree the backward-compatibility is highly important,
but here it prevents to fix bugs. Also I haven't found any documentation
which clearly explains the operations in detail, so I had to guess from the
repoinit examples what the operations are supposed to do. So the current
implementation does not contradict the documentation or specification
because there is none. But it contradicts the expectation I got from
reading the command. If there is a "DELETE USER" and a "DELETE SERVICE
USER" command, there must be different implementation behind it (otherwise
there would be only 1 command), and the obvious difference is the the
"DELETE SERVICE USER" deletes a service user.

I would also assume that any user of repoinit, who started based on the
existing documentation has the impression as I have and used the commands
in the same way; but I would question even that, because then this flaw in
the implementation would have been found much earlier.

So my proposal is to fix the bug, change the implementation in the
incompatible way (maybe add some log messages for the cases where the old
implementation would done the wrong thing) and document it properly. And
that's it.


-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

FYI, embedded Konrad's talk about servlet annotations in the Sling website

[Bertrand Delacretaz]

Hi,

I added that video at
https://sling.apache.org/documentation/the-sling-engine/servlets.html#registering-a-servlet-using-java-annotations
- we have some good recordings from adaptTo, I think it's worth adding
them when they are specific enough.

I haven't looked if there are other talks that would deserve the same
treatment but there's probably a few.

Or maybe we create a specific "videos" page and point to that where it
makes sense.

-Bertrand

Re: [jenkins] has anybody contacted INFRA?

[Robert Munteanu]

On Wed, 2018-10-03 at 12:03 +0200, Bertrand Delacretaz wrote:
> On Wed, Oct 3, 2018 at 11:30 AM Radu Cotescu  wrote:
> > https://builds.apache.org/view/S-Z/view/Sling-Dashboard/
> 
> Not me, and what I see is a 401 response when deploying artifacts,
> see below.
> 
> Are we missing deploy credentials somewhere maybe? I don't know off
> the top of my head how that's setup.

Not me either. Credentials are automatically inherited by jobs, I think
we should contact INFRA and ask them about this.

Robert

Re: [jenkins] has anybody contacted INFRA?

[Bertrand Delacretaz]

On Wed, Oct 3, 2018 at 11:30 AM Radu Cotescu  wrote:
> https://builds.apache.org/view/S-Z/view/Sling-Dashboard/

Not me, and what I see is a 401 response when deploying artifacts, see below.

Are we missing deploy credentials somewhere maybe? I don't know off
the top of my head how that's setup.

-Bertrand

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
(default-deploy) on project sling-bundle-archetype: Failed to deploy
artifacts: Could not transfer artifact
org.apache.sling:sling-bundle-archetype:jar:1.0.7-20180930.020546-32
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots): Failed
to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/sling-bundle-archetype/1.0.7-SNAPSHOT/sling-bundle-archetype-1.0.7-20180930.020546-32.jar.
Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]

and in another module

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
(default-deploy) on project org.apache.sling.api: Failed to deploy
artifacts: Could not transfer artifact
org.apache.sling:org.apache.sling.api:jar:2.18.5-20181002.121351-11
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots): Failed
to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/sling/org.apache.sling.api/2.18.5-SNAPSHOT/org.apache.sling.api-2.18.5-20181002.121351-11.jar.
Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]

[jenkins] has anybody contacted INFRA?

[Radu Cotescu]

https://builds.apache.org/view/S-Z/view/Sling-Dashboard/