RE: [RT] Improving access control

[Mike Müller]

I think the discussion here is missunderstood. It's neither about
to redefine existing ACLs nor about reinventing something already
existing. It's just about introducing hooks or entrypoint to let
developers define some other access controlling rules if needed.
Sling will NOT have to deal with permissions or policies, users and so
on. That's all up to the developer which want's to use the hooks.
So if you're are fine with the ACLs from JCR, you don't have to 
change anything, if you are not, this would give you the chance
to solve your problem (like my example to give access to a
resource from 8.00 to 17.00).
So 
It would help not only for special rules like the one above, it would
also help to handle access controlling on resources which are provided
from another resource provider than JCR, like the file system provider,
where no access controlling can be attached today.
And again: If someone is fine just with the JCR resource provider and
the ACLs, nothing will be more complicated after the introduction of
the hook than before.

best regards
mike


> -Original Message-
> From: Tobias Bocanegra [mailto:tri...@adobe.com]
> Sent: Wednesday, November 23, 2011 1:04 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] Improving access control
> 
> Hi,
> I fear the same, that sling tries to re-define and re-implement the
> whole JCR API stack (it already does for the most part :-(. Initially
> sling was a framework for building web application on top a JCR
> repository. But now it's a framework that happens to integrate nicely
> on JCR. I think the divergence to JCR started when the resource API
> was introduced. Although I like the idea and the elegance of the
> 'everything is a resource' approach, it in facts duplicates the JCR
> API.
> 
> Keep in mind that when you define any sort of Access Control API for
> sling, you eventually need to think about ACLs, Permissions, Policies,
> Privileges, Users, Principals, etc... All this is already specified by
> JCR or at least available in Jackrabbit. And as alex said: it only
> shields you on the resource provider level - but not on the JCR level.
> 
> btw: I'm not sure how far the support for custom policies in
> jackrabbit is, but the basics are there. So you can (and should)
> implement your 9am-5pm policy definitely on the repository level.
> 
> regards, toby

Re: [RT] Improving access control

[Tobias Bocanegra]

Hi,
I fear the same, that sling tries to re-define and re-implement the
whole JCR API stack (it already does for the most part :-(. Initially
sling was a framework for building web application on top a JCR
repository. But now it's a framework that happens to integrate nicely
on JCR. I think the divergence to JCR started when the resource API
was introduced. Although I like the idea and the elegance of the
'everything is a resource' approach, it in facts duplicates the JCR
API.

Keep in mind that when you define any sort of Access Control API for
sling, you eventually need to think about ACLs, Permissions, Policies,
Privileges, Users, Principals, etc... All this is already specified by
JCR or at least available in Jackrabbit. And as alex said: it only
shields you on the resource provider level - but not on the JCR level.

btw: I'm not sure how far the support for custom policies in
jackrabbit is, but the basics are there. So you can (and should)
implement your 9am-5pm policy definitely on the repository level.

regards, toby

[jira] [Updated] (SLING-2136) Sling POST Servlet: Configuration of Allowed Paths

[Tobias Bocanegra (Updated) (JIRA)]

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

Tobias Bocanegra updated SLING-2136:


Attachment: post_servlet_filter-1205238.patch

Patch that introduces a new configuration for a simple
allow/deny path filter list.

> Sling POST Servlet: Configuration of Allowed Paths
> --
>
> Key: SLING-2136
> URL: https://issues.apache.org/jira/browse/SLING-2136
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Affects Versions: Servlets Post 2.1.2
>Reporter: Andrew Khoury
> Attachments: post_servlet_filter-1205238.patch
>
>
> It would be nice if you could configure rules or regular expressions for 
> paths the sling post servlet is allowed to work under.  This would be good 
> for both security reasons and for protecting against conflicts with other 
> servlets.
> For example:
> Let's say you have a servlet ReplicationServlet registered to receive POST 
> requests under path /bin/replicate.
> However, during startup, before the ReplicationServlet component has been 
> enabled, a user tries to do a POST to /bin/replicate.  In this case, instead 
> of executing the ReplicationServlet, the POST servlet is executed and it 
> creates a node under /bin/replicate.  Now, as long as the node /bin/replicate 
> exists... the ReplicationServlet will not be executed for requests to 
> /bin/replicate.  This presents a problem and explains the necessity for this 
> feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RT] Improving access control

[Alexander Klimetschek]

But again the question (as asked by me and Vidar): why does Sling need
that?

What is wrong with a resource provider simply not returning resources
where the user has no access, as it is already the case with the JCR
provider?

Cheers,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [RT] Improving access control

[Sarwar Bhuiyan]

In any case, setting the scr property to specify the access control
service/class still holds as it allows us to set an initial value using scr
annotations and also we can reuse or reconfigure access control provider
for each resource provider.

Just an idea instead of making the resource provider itself implement the
access control logic.

Sarwar
On Nov 22, 2011 6:46 PM, "Bertrand Delacretaz" 
wrote:

> On Tue, Nov 22, 2011 at 6:37 PM, Sarwar Bhuiyan
>  wrote:
> > ...Bertrand asked what user interface we could use to configure an access
> > control provider...
>
> Sorry, my question was badly phrased: what I meant is that people
> already need to have a UI to configure JCR access control - if this
> new feature requires a different UI it would be a Bad Thing.
>
> And as Carsten mentioned this UI question was not really relevant
> anyway, as this thread is only about providing a low-level mechanism
> to block access to certain resources.
>
> -Bertrand
>

Re: [RT] Improving access control

[Bertrand Delacretaz]

On Tue, Nov 22, 2011 at 6:37 PM, Sarwar Bhuiyan
 wrote:
> ...Bertrand asked what user interface we could use to configure an access
> control provider...

Sorry, my question was badly phrased: what I meant is that people
already need to have a UI to configure JCR access control - if this
new feature requires a different UI it would be a Bad Thing.

And as Carsten mentioned this UI question was not really relevant
anyway, as this thread is only about providing a low-level mechanism
to block access to certain resources.

-Bertrand

Build failed in Jenkins: sling-contrib-1.5 #767

[Apache Jenkins Server]

See 

--
[...truncated 3002 lines...]
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.scripting.scala.hello-world/0.9.0-SNAPSHOT/org.apache.sling.scripting.scala.hello-world-0.9.0-SNAPSHOT.jar
 to 

[INFO] snapshot 
org.apache.sling:org.apache.sling.scripting.scala.forum:0.9.0-SNAPSHOT: 
checking for updates from apache.snapshots
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.scripting.scala.forum/0.9.0-SNAPSHOT/org.apache.sling.scripting.scala.forum-0.9.0-SNAPSHOT.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/servicemix/bundles/org.apache.servicemix.bundles.scala-library/2.8.1_1/org.apache.servicemix.bundles.scala-library-2.8.1_1.jar
 to 

[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/servicemix/bundles/org.apache.servicemix.bundles.scala-compiler/2.8.1_1/org.apache.servicemix.bundles.scala-compiler-2.8.1_1.jar
 to 

[INFO] snapshot 
org.apache.sling:org.apache.sling.scripting.xproc:2.0.0-SNAPSHOT: checking for 
updates from apache.snapshots
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.scripting.xproc/2.0.0-SNAPSHOT/org.apache.sling.scripting.xproc-2.0.0-SNAPSHOT.jar
 to 

[INFO] snapshot 
org.apache.sling:org.apache.sling.extensions.apt.servlet:2.0.3-SNAPSHOT: 
checking for updates from apache.snapshots
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.extensions.apt.servlet/2.0.3-SNAPSHOT/org.apache.sling.extensions.apt.servlet-2.0.3-SNAPSHOT.jar
 to 

[INFO] snapshot 
org.apache.sling:org.apache.sling.extensions.apt.parser:2.0.3-SNAPSHOT: 
checking for updates from apache.snapshots
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/org.apache.sling.extensions.apt.parser/2.0.3-SNAPSHOT/org.apache.sling.extensions.apt.parser-2.0.3-SNAPSHOT.jar
 to 

[INFO] snapshot 
org.apache.sling.samples:org.apache.sling.samples.path-based.rtp:2.0.5-SNAPSHOT:
 checking for updates from apache.snapshots
Downloading: 
http://repository.apache.org/snapshots/org/apache/sling/samples/org.apache.sling.samples.path-based.rtp/2.0.5-SNAPSHOT/org.apache.sling.samples.path-based.rtp-2.0.5-SNAPSHOT.jar
[INFO] Copying bundle from 
/home/jenkins/.m2/repository/org/apache/sling/samples/org.apache.sling.samples.path-based.rtp/2.0.5-SNAPSHOT/org.apache.sling.samples.path-based.rtp-2.0.5-SNAPSHOT.jar
 to 

[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 3 resources
[INFO] [build-helper:reserve-network-port {execution: reserve-network-port}]
[INFO] Reserved port 46855 for http.port
[WARNING] DEPRECATED [tasks]: Use target instead
[INFO] [antrun:run {execution: default}]
[WARNING] Parameter tasks is deprecated, use target instead
[INFO] Executing tasks

main:
 [echo]  WARNING (SLING-443/SLING-1782) 
**
 [echo] On most platforms, you'll get OutOfMemoryErrors when building 
unless you set
 [echo] on 32bit platforms: MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=256M", see 
SLING-443
 [echo] on 64bit platforms: MAVEN_OPTS="-Xmx512M -XX:MaxPermSize=512M", see 
SLING-1782
 [echo] 
*

Jenkins build is back to stable : sling-trunk-1.6 #1125

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #1125

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1125

[Apache Jenkins Server]

See 

Re: [RT] Improving access control

[Sarwar Bhuiyan]

Hi all,

Bertrand asked what user interface we could use to configure an access
control provider.  We could do some wiring based on an osgi property, if it
exists, using an scr annotation on the resource provider to specify the
service which implements the access control gate (if one is not provided,
use the JCR acl).  The SlingMainServlet would check for this and call the
appropriate method (e.g. acceptResource or whatever).

This way, the access control provider can be reused by different resource
providers and we can change it in the OSGi console if required.  The actual
implementation can take care of whether to accept read, write, modify, etc.

WDYT?

Sarwar

On Tue, Nov 22, 2011 at 4:11 PM, Carsten Ziegeler wrote:

> 2011/11/22 Bertrand Delacretaz :
> > On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler 
> wrote:
> >> 2011/11/22 Vidar Ramdal :
> >>>... I'm coming late to this party, but having read the thread I'm not
> sure
> >>> if the proposal is about a) specifying access control APIs to be
> >>> implemented by resource providers, or b) implement access control
> >>> logic independently from (on top of) resource providers
> >
> >> ...the idea is about b) - I agree that thinks like search might get a
> >> little bit...well...interesting :) Though if you use the Sling search,
> >> you get resources and they will go through the same check mechanism
> >
> > Can this be done with a service interface like this, or is there more to
> it?
> >
> > public interface ResourceAccessGate {
> >  /** @return false if access to the supplied Resource is denied for
> > supplied request */
> >  boolean acceptResource(SlingHttpServletRequest request, Resource
> resource);
> > }
>
> Something similar - though we won't pass a request object into the
> check just the resource (resources can be get without a request) and
> we need to think about how to handle create.
>
> Now, as indicated this is an RT :) I think we won't implement this in
> the next days (patches welcome of course), but as soon as we split the
> resource resolver from the jcr provider, things like these get even
> more interesting (and get easier to implement hopefully)
>
> Regards
> Carsten
>
> >
> > If that's what you mean, I'd be ok as long as we clearly indicate that
> > this is just an additional application-level access gate, not to be
> > confused with ACLs which are handled at the repository level.
> >
> > Just something like the ResourceDecorator that we already have (and
> > both will be called in the same places probably).
> >
> > -Bertrand
> >
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>

[jira] [Commented] (SLING-2290) Updating a fragment with a different version but the same content does not work

[Carsten Ziegeler (Commented) (JIRA)]

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

Carsten Ziegeler commented on SLING-2290:
-

Thanks Konrad for your test case!

> Updating a fragment with a different version but the same content does not 
> work
> ---
>
> Key: SLING-2290
> URL: https://issues.apache.org/jira/browse/SLING-2290
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.2.4, JCR Installer 3.1.2
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.2.4
>
> Attachments: simplebundle-0.0.1-SNAPSHOT.jar, 
> simplebundle-0.0.2-SNAPSHOT.jar, simplebundle-0.0.2-SNAPSHOT.jar
>
>
> If you update a bundle through a JCR package, it is only updated in Apache 
> Felix if the actual content has changed. It is not enough to have the version 
> number changed. This is a problem, because usually in multimodule maven 
> builds I increase the version for all contained bundles although they might 
> not have changed in that release. Unfortunately the new version is not 
> deployed, therefore the Webconsole still shows the old version.
> The same problem applies to Bundle Fragments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is back to stable : sling-trunk-1.5 #1450

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1450

[Apache Jenkins Server]

See 

Jenkins build is back to stable : sling-trunk-1.5 » Apache Sling Launchpad Testing #1450

[Apache Jenkins Server]

See 

Re: [RT] Improving access control

[Carsten Ziegeler]

2011/11/22 Bertrand Delacretaz :
> On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler  
> wrote:
>> 2011/11/22 Vidar Ramdal :
>>>... I'm coming late to this party, but having read the thread I'm not sure
>>> if the proposal is about a) specifying access control APIs to be
>>> implemented by resource providers, or b) implement access control
>>> logic independently from (on top of) resource providers
>
>> ...the idea is about b) - I agree that thinks like search might get a
>> little bit...well...interesting :) Though if you use the Sling search,
>> you get resources and they will go through the same check mechanism
>
> Can this be done with a service interface like this, or is there more to it?
>
> public interface ResourceAccessGate {
>  /** @return false if access to the supplied Resource is denied for
> supplied request */
>  boolean acceptResource(SlingHttpServletRequest request, Resource resource);
> }

Something similar - though we won't pass a request object into the
check just the resource (resources can be get without a request) and
we need to think about how to handle create.

Now, as indicated this is an RT :) I think we won't implement this in
the next days (patches welcome of course), but as soon as we split the
resource resolver from the jcr provider, things like these get even
more interesting (and get easier to implement hopefully)

Regards
Carsten

>
> If that's what you mean, I'd be ok as long as we clearly indicate that
> this is just an additional application-level access gate, not to be
> confused with ACLs which are handled at the repository level.
>
> Just something like the ResourceDecorator that we already have (and
> both will be called in the same places probably).
>
> -Bertrand
>



-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Resolved] (SLING-2298) Register web console plugin using a ServiceFactory

[Carsten Ziegeler (Resolved) (JIRA)]

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

Carsten Ziegeler resolved SLING-2298.
-

Resolution: Fixed

Changed in revision 1205052

> Register web console plugin using a ServiceFactory
> --
>
> Key: SLING-2298
> URL: https://issues.apache.org/jira/browse/SLING-2298
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.2.2
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.2.4
>
>
> Currently the web console plugin is tried to be directly registered which 
> fails if the javax.servlet api is not available at that moment. This results 
> in a missing plugin if the osgi installer starts before the javax servlet 
> package. 
> Instead of directly trying to register we could register a service factory 
> instead which is the first time queried when the web console is started and 
> then the required api's are available.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RT] Improving access control

[Bertrand Delacretaz]

On Tue, Nov 22, 2011 at 4:39 PM, Carsten Ziegeler  wrote:
> 2011/11/22 Vidar Ramdal :
>>... I'm coming late to this party, but having read the thread I'm not sure
>> if the proposal is about a) specifying access control APIs to be
>> implemented by resource providers, or b) implement access control
>> logic independently from (on top of) resource providers

> ...the idea is about b) - I agree that thinks like search might get a
> little bit...well...interesting :) Though if you use the Sling search,
> you get resources and they will go through the same check mechanism

Can this be done with a service interface like this, or is there more to it?

public interface ResourceAccessGate {
  /** @return false if access to the supplied Resource is denied for
supplied request */
  boolean acceptResource(SlingHttpServletRequest request, Resource resource);
}

If that's what you mean, I'd be ok as long as we clearly indicate that
this is just an additional application-level access gate, not to be
confused with ACLs which are handled at the repository level.

Just something like the ResourceDecorator that we already have (and
both will be called in the same places probably).

-Bertrand

RE: [RT] Improving access control

[Mike Müller]

> 2011/11/22 Bertrand Delacretaz :
> > On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler  
> > wrote:
> >> This idea is about to provide a general approach for resource
> >> checking
> >>...
> >> Think in terms of our resource abstraction - so far I don't see the
> >> need to define any API to set/change/query these additional checks
> >> within Sling.
> >
> > But these restrictions on resource access will need to be defined
> > somewhere, right?
> > How do you see this?
> >
> I don't care :) We just provide the interface/hook to do that. If
> you're using a repository then maybe the shadow tree is a good
> approach. If you don't have a repo, you need something else.
> In some cases, you might just want to check if the current user is
> admin and allow things, or if the user is authenticated at all. Or you
> want to query your LDAP. Or variations on the theme.
> 
> We're providing a framework which should not prevent users from doing
> their stuff - and as we see with Mike's case, there are valid use
> cases.
> 
> And even with doing the jcr shadow tree or something like on/off times
> in the repository, with the provided interface you have a good way of
> hooking this into the system :)

+1
It's not about avoiding JCR ACLs, it's more about to make the access
controlling more flexible and independent from the JCR. But the feature
should not prevent the user just to use JCR ACLs. 
So the extension is built only as a service interface to "intercept" the
normal flow if needed.

best regards
mike

Re: [RT] Improving access control

[Carsten Ziegeler]

2011/11/22 Vidar Ramdal :
> 2011/11/22 Carsten Ziegeler :
>> This idea is about to provide a general approach for resource
>> checking. Noone prevents you from doing a virtual tree in the jcr
>> repository to check access of resources provided by other providers.
>> But that's an implementation detail which I don't want to require
>> upfront!
>
> I'm coming late to this party, but having read the thread I'm not sure
> if the proposal is about a) specifying access control APIs to be
> implemented by resource providers, or b) implement access control
> logic independently from (on top of) resource providers.
> Can someone clarify?
>
> With b), it would be easy to re-use access control logic across
> resource providers (like the 9:00-17:00 rule), but I suspect it will
> introduce other problems, such as with Jackrabbit's Lucene search
> results - you don't want to return a search result that the user don't
> have access to.
>
> With a), we simply delegate all access control to resource providers
> (like JCR), which will pretend a resource does not exist if the user
> has no access to it. But then, what will be the point of having Sling
> APIs for access control? In other words, why does Sling need to know
> that a resource exists, when it is unaccessible for the user?
>
Hi,

the idea is about b) - I agree that thinks like search might get a
little bit...well...interesting :) Though if you use the Sling search,
you get resources and they will go through the same check mechanism.

Sure, we could go with a) but this would require to forsee such checks
in each and every resource provider and accordingly configure it for
each provider. This is something I wanted to avoid. Use cases like
Mike's sound to fit perfectly into b).

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

Re: [RT] Improving access control

[Vidar Ramdal]

2011/11/22 Carsten Ziegeler :
> This idea is about to provide a general approach for resource
> checking. Noone prevents you from doing a virtual tree in the jcr
> repository to check access of resources provided by other providers.
> But that's an implementation detail which I don't want to require
> upfront!

I'm coming late to this party, but having read the thread I'm not sure
if the proposal is about a) specifying access control APIs to be
implemented by resource providers, or b) implement access control
logic independently from (on top of) resource providers.
Can someone clarify?

With b), it would be easy to re-use access control logic across
resource providers (like the 9:00-17:00 rule), but I suspect it will
introduce other problems, such as with Jackrabbit's Lucene search
results - you don't want to return a search result that the user don't
have access to.

With a), we simply delegate all access control to resource providers
(like JCR), which will pretend a resource does not exist if the user
has no access to it. But then, what will be the point of having Sling
APIs for access control? In other words, why does Sling need to know
that a resource exists, when it is unaccessible for the user?

-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [RT] Improving access control

[Alexander Klimetschek]

On 22.11.11 14:17, "Carsten Ziegeler"  wrote:

>This idea is about to provide a general approach for resource
>checking. Noone prevents you from doing a virtual tree in the jcr
>repository to check access of resources provided by other providers.
>But that's an implementation detail which I don't want to require
>upfront!

I just expect that if Sling provides some simple ACL interfaces, people
will start to implement them (w/o ever looking into what JCR ACLs they can
have or implement) and only later detect & complain that it only works
when you do everything in Sling's resource API.

BTW: Where does Sling need resource checking? If something is not
accessible = readable, it should simply not be returned from the resource
provider (as JCR does).

Cheers,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

[jira] [Created] (SLING-2298) Register web console plugin using a ServiceFactory

[Carsten Ziegeler (Created) (JIRA)]

Register web console plugin using a ServiceFactory
--

 Key: SLING-2298
 URL: https://issues.apache.org/jira/browse/SLING-2298
 Project: Sling
  Issue Type: Improvement
  Components: Installer
Affects Versions: Installer Core 3.2.2
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Installer Core 3.2.4


Currently the web console plugin is tried to be directly registered which fails 
if the javax.servlet api is not available at that moment. This results in a 
missing plugin if the osgi installer starts before the javax servlet package. 
Instead of directly trying to register we could register a service factory 
instead which is the first time queried when the web console is started and 
then the required api's are available.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2290) Updating a fragment with a different version but the same content does not work

[Carsten Ziegeler (Resolved) (JIRA)]

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

Carsten Ziegeler resolved SLING-2290.
-

   Resolution: Fixed
Fix Version/s: Installer Core 3.2.4

Fixed in revision 1205016 - the problem was due to the attempt of stopping a 
fragment before the actual update.
I've also refactored the code a little bit to make it cleaner and change the 
package refresh handling to a minimum.

> Updating a fragment with a different version but the same content does not 
> work
> ---
>
> Key: SLING-2290
> URL: https://issues.apache.org/jira/browse/SLING-2290
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.2.4, JCR Installer 3.1.2
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.2.4
>
> Attachments: simplebundle-0.0.1-SNAPSHOT.jar, 
> simplebundle-0.0.2-SNAPSHOT.jar, simplebundle-0.0.2-SNAPSHOT.jar
>
>
> If you update a bundle through a JCR package, it is only updated in Apache 
> Felix if the actual content has changed. It is not enough to have the version 
> number changed. This is a problem, because usually in multimodule maven 
> builds I increase the version for all contained bundles although they might 
> not have changed in that release. Unfortunately the new version is not 
> deployed, therefore the Webconsole still shows the old version.
> The same problem applies to Bundle Fragments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2297) JspScriptingTest.testChangingJsp failing

[Felix Meschberger (Resolved) (JIRA)]

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

Felix Meschberger resolved SLING-2297.
--

Resolution: Cannot Reproduce

After properly fixing SLING-2296 this issue goes away, too.

> JspScriptingTest.testChangingJsp failing
> 
>
> Key: SLING-2297
> URL: https://issues.apache.org/jira/browse/SLING-2297
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.0.18
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
>
> Probably related to SLING-2296 the JspScriptingTest.testChangingJsp test is 
> failing now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Resolved) (JIRA)]

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

Felix Meschberger resolved SLING-2296.
--

Resolution: Fixed

Looks like the issue is now fixed. Thus resolving this issue again.

> Transient ResourceResolver bundle build failure on Linux
> 
>
> Key: SLING-2296
> URL: https://issues.apache.org/jira/browse/SLING-2296
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.1.0
>
>
> Often times I get build failures of the JCR ResourceResolver Bundle:
>   
> testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
>  expected:<3> but was:<1>
>   testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
> expected:<3> but was:<1>
> Looking and tracing the code it seems that the JcrResourceListener gets the 
> JCR events and handles them correctly. But the sendOsgiEvent method does not 
> actually forward the event. This is caused by the JcrResourceListener's 
> internal resource resolver not (yet ?) knowing the added or changed resource 
> and thus not being able to read it to get the resource type.
> The sendOsgiEvent method should be modified to make sure the event is sent 
> regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RT] Improving access control

[Carsten Ziegeler]

2011/11/22 Bertrand Delacretaz :
> On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler  
> wrote:
>> This idea is about to provide a general approach for resource
>> checking
>>...
>> Think in terms of our resource abstraction - so far I don't see the
>> need to define any API to set/change/query these additional checks
>> within Sling.
>
> But these restrictions on resource access will need to be defined
> somewhere, right?
> How do you see this?
>
I don't care :) We just provide the interface/hook to do that. If
you're using a repository then maybe the shadow tree is a good
approach. If you don't have a repo, you need something else.
In some cases, you might just want to check if the current user is
admin and allow things, or if the user is authenticated at all. Or you
want to query your LDAP. Or variations on the theme.

We're providing a framework which should not prevent users from doing
their stuff - and as we see with Mike's case, there are valid use
cases.

And even with doing the jcr shadow tree or something like on/off times
in the repository, with the provided interface you have a good way of
hooking this into the system :)

Regards
Carsten
-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Commented) (JIRA)]

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

Felix Meschberger commented on SLING-2296:
--

Committed another fix in Rev. 1205007 which updates the path on the event 
properly for nt:file's content.

> Transient ResourceResolver bundle build failure on Linux
> 
>
> Key: SLING-2296
> URL: https://issues.apache.org/jira/browse/SLING-2296
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.1.0
>
>
> Often times I get build failures of the JCR ResourceResolver Bundle:
>   
> testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
>  expected:<3> but was:<1>
>   testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
> expected:<3> but was:<1>
> Looking and tracing the code it seems that the JcrResourceListener gets the 
> JCR events and handles them correctly. But the sendOsgiEvent method does not 
> actually forward the event. This is caused by the JcrResourceListener's 
> internal resource resolver not (yet ?) knowing the added or changed resource 
> and thus not being able to read it to get the resource type.
> The sendOsgiEvent method should be modified to make sure the event is sent 
> regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Reopened) (JIRA)]

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

Felix Meschberger reopened SLING-2296:
--


The fix is not entirely correct: If the event is for a jar:content node and the 
resource is available to the sendOsgiEvent method, the check is done whether it 
is an nt:file content but this has no consequence for the path set on the event.

This causes JSP changes to not be properly reflected and thus the 
JspScriptingTest.testChangingJsp (SLING-2297) to fail.

> Transient ResourceResolver bundle build failure on Linux
> 
>
> Key: SLING-2296
> URL: https://issues.apache.org/jira/browse/SLING-2296
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.1.0
>
>
> Often times I get build failures of the JCR ResourceResolver Bundle:
>   
> testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
>  expected:<3> but was:<1>
>   testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
> expected:<3> but was:<1>
> Looking and tracing the code it seems that the JcrResourceListener gets the 
> JCR events and handles them correctly. But the sendOsgiEvent method does not 
> actually forward the event. This is caused by the JcrResourceListener's 
> internal resource resolver not (yet ?) knowing the added or changed resource 
> and thus not being able to read it to get the resource type.
> The sendOsgiEvent method should be modified to make sure the event is sent 
> regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RT] Improving access control

[Bertrand Delacretaz]

On Tue, Nov 22, 2011 at 2:43 PM, Vidar Ramdal  wrote:
> 2011/11/22 Bertrand Delacretaz :
>> ...To keep things simple I'd suggest using a "shadow resource tree" in
>> JCR if we need to define access control for ResourceResolvers which
>> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
>> repository node define ACL for resource /foo provided by provider
>> com.example.bar, for example.
>
> Hmm, so you are thinking about delegating access control for all kind
> of resources to JCR? Wouldn't that just duplicate resource trees from
> (all) other resource providers into JCR, just for the sake of access
> control?...

The shadow tree could use wildcards, if we want to go that way.

-Bertrand

Re: [RT] Improving access control

[Vidar Ramdal]

2011/11/22 Bertrand Delacretaz :
> On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
>  wrote:
>> ...Personally I think it is much better to put such additional ACL
>> implementations into the JCR (e.g. a custom Jackrabbit access control
>> provider). The problem is that anytime your code is using JCR (such as for
>> complex operations not possible through the simple resource API) your
>> sling-based access control won't be used at all
>
> Right...adding an ACL layer that's not based on JCR might generate a
> lot of confusion IMO.
> [...]
> To keep things simple I'd suggest using a "shadow resource tree" in
> JCR if we need to define access control for ResourceResolvers which
> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
> repository node define ACL for resource /foo provided by provider
> com.example.bar, for example.

Hmm, so you are thinking about delegating access control for all kind
of resources to JCR? Wouldn't that just duplicate resource trees from
(all) other resource providers into JCR, just for the sake of access
control?


-- 
Vidar S. Ramdal 
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo

Re: [RT] Improving access control

[Bertrand Delacretaz]

On Tue, Nov 22, 2011 at 2:17 PM, Carsten Ziegeler  wrote:
> This idea is about to provide a general approach for resource
> checking
>...
> Think in terms of our resource abstraction - so far I don't see the
> need to define any API to set/change/query these additional checks
> within Sling.

But these restrictions on resource access will need to be defined
somewhere, right?
How do you see this?

-Bertrand

[jira] [Created] (SLING-2297) JspScriptingTest.testChangingJsp failing

[Felix Meschberger (Created) (JIRA)]

JspScriptingTest.testChangingJsp failing


 Key: SLING-2297
 URL: https://issues.apache.org/jira/browse/SLING-2297
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting JSP 2.0.18
Reporter: Felix Meschberger
Assignee: Felix Meschberger


Probably related to SLING-2296 the JspScriptingTest.testChangingJsp test is 
failing now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RT] Improving access control

[Carsten Ziegeler]

This idea is about to provide a general approach for resource
checking. Noone prevents you from doing a virtual tree in the jcr
repository to check access of resources provided by other providers.
But that's an implementation detail which I don't want to require
upfront!

Think in terms of our resource abstraction - so far I don't see the
need to define any API to set/change/query these additional checks
within Sling.

Regards
Carsten

2011/11/22 Bertrand Delacretaz :
> On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
>  wrote:
>> ...Personally I think it is much better to put such additional ACL
>> implementations into the JCR (e.g. a custom Jackrabbit access control
>> provider). The problem is that anytime your code is using JCR (such as for
>> complex operations not possible through the simple resource API) your
>> sling-based access control won't be used at all
>
> Right...adding an ACL layer that's not based on JCR might generate a
> lot of confusion IMO.
>
> And where are we going to implement user/RESTful interfaces for
> defining such ACLs? New additional APIs and UIs?
>
> To keep things simple I'd suggest using a "shadow resource tree" in
> JCR if we need to define access control for ResourceResolvers which
> are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
> repository node define ACL for resource /foo provided by provider
> com.example.bar, for example.
>
> That doesn't solve Mike's time-based ACLs, but I'd handle those
> separately at the application level (or in a Filter) anyway. Having
> ACLs that depend on something else than the current request's
> credentials might break too many existing semantics (caching etc).
>
> -Bertrand
>



-- 
Carsten Ziegeler
cziege...@apache.org

Re: [RT] Improving access control

[Bertrand Delacretaz]

On Tue, Nov 22, 2011 at 1:45 PM, Alexander Klimetschek
 wrote:
> ...Personally I think it is much better to put such additional ACL
> implementations into the JCR (e.g. a custom Jackrabbit access control
> provider). The problem is that anytime your code is using JCR (such as for
> complex operations not possible through the simple resource API) your
> sling-based access control won't be used at all

Right...adding an ACL layer that's not based on JCR might generate a
lot of confusion IMO.

And where are we going to implement user/RESTful interfaces for
defining such ACLs? New additional APIs and UIs?

To keep things simple I'd suggest using a "shadow resource tree" in
JCR if we need to define access control for ResourceResolvers which
are not JCR: have the /SLING-ACL/resolvers/com.example.bar/foo
repository node define ACL for resource /foo provided by provider
com.example.bar, for example.

That doesn't solve Mike's time-based ACLs, but I'd handle those
separately at the application level (or in a Filter) anyway. Having
ACLs that depend on something else than the current request's
credentials might break too many existing semantics (caching etc).

-Bertrand

Re: [RT] Improving access control

[Alexander Klimetschek]

On 22.11.11 11:15, "Mike Müller"  wrote:
>We're at MySign thought about such a access control layer in Sling a few
>months ago. Mainly because we do have different resource providers
>without the possibility of ACLs and also because some access rules
>can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
>We do have such an access layer in our legacy framework and there
>we also have the possibility to define the access rules declarative (like
>ACLs) but also by somtehing like the proposed ResourceAccessController
>services.

Personally I think it is much better to put such additional ACL
implementations into the JCR (e.g. a custom Jackrabbit access control
provider). The problem is that anytime your code is using JCR (such as for
complex operations not possible through the simple resource API) your
sling-based access control won't be used at all.

Cheers,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Jenkins build became unstable: sling-trunk-1.6 #1124

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1124

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1124

[Apache Jenkins Server]

See 

RE: [RT] Improving access control

[Mike Müller]

> I share the performance concern if a jcr node has to be checked twice
> as this would double the repository access per request.
> 
> In general I think we can go with this (for reading):
> 1. ResourceProvider delivers resource and maybe does already the ACL
> check (like in the JCR case)
> 2. ResourceAccessController do additional checks
> 
> This is a general approach, avoids duplicate checks and ensures that
> it's not possible to circumvent JCR ACLs.

+1
Step 2) can be skipped, if no resource is returned.
And in addition this gives us the possibility to pass the found resource to
the ResourceAccessController. That enables a specific ResourceAccessController
to make the decision  to allow or deny access to this ressource dependent
on the data of the resource and not only the path of the resource.

best regards
mike

> 
> As mentioned, the only potential drawback is that for the same path
> different users might end up with different resources. But I think we
> can live with that.
> 
> Regards
> Carsten
> 
> 2011/11/22 Mike Müller :
> > Okay, I might be a little bit late in the discussion...
> > We're at MySign thought about such a access control layer in Sling a few
> > months ago. Mainly because we do have different resource providers
> > without the possibility of ACLs and also because some access rules
> > can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
> > We do have such an access layer in our legacy framework and there
> > we also have the possibility to define the access rules declarative (like
> > ACLs) but also by somtehing like the proposed ResourceAccessController
> > services.
> >
> > I do share Justins fear, that we get poor performance if we do have to
> > call the JCR provider twice to once get to know if the user has access and
> > once to get the resource. But maybe the JCR resource provider can cache
> > the resource from the first call and the performance ist fine.
> > I think we should not design a general architecture for access controlling
> > an make the JCR a special case. I would prefer a "clean" design with only
> > one service interface for access controlling (without exceptions).
> > The approach where the ResourceProvider implements it's own access
> > control mechanism avoids the possibility for a special 
> > ResourceAccessController
> > to overwrite some access roles (like the example above with access
> > between 8.00 and 17.00). Plus, it would be less understandable than the
> > clean approach with just one entry point where access controlling is
> > taking place.
> >
> > What I missed in the discussion so far is, that the proposed mechanisms
> > are only usable for read. I think a general access controller mechanism in
> > Sling should provide access controlling for read, write, modify and delete.
> > With such an architecture it would be much easier to control security 
> > aspects
> > of the application.
> >
> > best regards
> > mike
> >
> >
> >> -Original Message-
> >> From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of
> Justin
> >> Edelson
> >> Sent: Tuesday, November 15, 2011 5:24 AM
> >> To: dev@sling.apache.org
> >> Subject: Re: [RT] Improving access control
> >>
> >> Thanks for the clarification Julian. This makes more sense. I have two
> >> concerns with the variant you're describing:
> >>
> >> 1) It does not provide a way for ResourceProvider implementers to
> >> provide their own access control mechanism, which is one thing I
> >> really liked in Carsten's original proposal.
> >> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
> >> poor performance because the access control rules in the repository
> >> will be evaluated twice.
> >>
> >> Justin
> >>
> >> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding  wrote:
> >> > Hi Justin
> >> >
> >> > Carsten's original proposal introduced two ways to handle access
> >> > control: ACLAwareResourceProvider and ResourceAccessController.
> >> >
> >> > The ACLAwareResourceProvider would act just like JCR Resources are
> >> > currently handled, i.e. with access control already enforced by the
> >> > underlying storage layer. The interface would merely indicate that
> >> > this ResourceProvider takes care of access control by itself (and
> >> > should presumably bypass any ResourceAccessController services).
> >> >
> >> > ResourceAccessController would be a new concept and interface, which
> >> > allows different implementations as services. A
> >> > ResourceAccessController (presumably again) indicates whether access
> >> > is granted or denied.
> >> >
> >> > The variation I propose is to drop the ACLAwareResourceProvider
> >> > concept and implement a ResourceAccessController for JCR resources
> >> > instead. The implementation would grant or deny access to a resource
> >> > based on ACLs in Jackrabbit.
> >> >
> >> > So a request for /foo would hit the SlingMainServlet, then the
> >> > Authenticator. Let's assume we now have a known user, we 

Jenkins build became unstable: sling-trunk-1.5 #1449

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing WAR version #1449

[Apache Jenkins Server]

See 

Jenkins build became unstable: sling-trunk-1.5 » Apache Sling Launchpad Testing #1449

[Apache Jenkins Server]

See 

Re: [RT] Improving access control

[Carsten Ziegeler]

Hi Mike,

thanks for your valuable input!

Yes, though we didn't talk about it, these checks should not only
apply for reading but in general for all operations.

I share the performance concern if a jcr node has to be checked twice
as this would double the repository access per request.

In general I think we can go with this (for reading):
1. ResourceProvider delivers resource and maybe does already the ACL
check (like in the JCR case)
2. ResourceAccessController do additional checks

This is a general approach, avoids duplicate checks and ensures that
it's not possible to circumvent JCR ACLs.

As mentioned, the only potential drawback is that for the same path
different users might end up with different resources. But I think we
can live with that.

Regards
Carsten

2011/11/22 Mike Müller :
> Okay, I might be a little bit late in the discussion...
> We're at MySign thought about such a access control layer in Sling a few
> months ago. Mainly because we do have different resource providers
> without the possibility of ACLs and also because some access rules
> can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
> We do have such an access layer in our legacy framework and there
> we also have the possibility to define the access rules declarative (like
> ACLs) but also by somtehing like the proposed ResourceAccessController
> services.
>
> I do share Justins fear, that we get poor performance if we do have to
> call the JCR provider twice to once get to know if the user has access and
> once to get the resource. But maybe the JCR resource provider can cache
> the resource from the first call and the performance ist fine.
> I think we should not design a general architecture for access controlling
> an make the JCR a special case. I would prefer a "clean" design with only
> one service interface for access controlling (without exceptions).
> The approach where the ResourceProvider implements it's own access
> control mechanism avoids the possibility for a special 
> ResourceAccessController
> to overwrite some access roles (like the example above with access
> between 8.00 and 17.00). Plus, it would be less understandable than the
> clean approach with just one entry point where access controlling is
> taking place.
>
> What I missed in the discussion so far is, that the proposed mechanisms
> are only usable for read. I think a general access controller mechanism in
> Sling should provide access controlling for read, write, modify and delete.
> With such an architecture it would be much easier to control security aspects
> of the application.
>
> best regards
> mike
>
>
>> -Original Message-
>> From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of 
>> Justin
>> Edelson
>> Sent: Tuesday, November 15, 2011 5:24 AM
>> To: dev@sling.apache.org
>> Subject: Re: [RT] Improving access control
>>
>> Thanks for the clarification Julian. This makes more sense. I have two
>> concerns with the variant you're describing:
>>
>> 1) It does not provide a way for ResourceProvider implementers to
>> provide their own access control mechanism, which is one thing I
>> really liked in Carsten's original proposal.
>> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
>> poor performance because the access control rules in the repository
>> will be evaluated twice.
>>
>> Justin
>>
>> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding  wrote:
>> > Hi Justin
>> >
>> > Carsten's original proposal introduced two ways to handle access
>> > control: ACLAwareResourceProvider and ResourceAccessController.
>> >
>> > The ACLAwareResourceProvider would act just like JCR Resources are
>> > currently handled, i.e. with access control already enforced by the
>> > underlying storage layer. The interface would merely indicate that
>> > this ResourceProvider takes care of access control by itself (and
>> > should presumably bypass any ResourceAccessController services).
>> >
>> > ResourceAccessController would be a new concept and interface, which
>> > allows different implementations as services. A
>> > ResourceAccessController (presumably again) indicates whether access
>> > is granted or denied.
>> >
>> > The variation I propose is to drop the ACLAwareResourceProvider
>> > concept and implement a ResourceAccessController for JCR resources
>> > instead. The implementation would grant or deny access to a resource
>> > based on ACLs in Jackrabbit.
>> >
>> > So a request for /foo would hit the SlingMainServlet, then the
>> > Authenticator. Let's assume we now have a known user, we ask any
>> > ResourceAccessController services if the user is granted access. If
>> > access is denied, an appropriate response is sent (e.g. 403). If
>> > access is granted, the ResourceProviders will be asked for the
>> > resource. If the resource is unavailable, a 404 response can be sent,
>> > otherwise Sling renders the resource.
>> >
>> > I'm not using the term ACL, as the ResourceAccessController

RE: [RT] Improving access control

[Mike Müller]

Okay, I might be a little bit late in the discussion...
We're at MySign thought about such a access control layer in Sling a few
months ago. Mainly because we do have different resource providers
without the possibility of ACLs and also because some access rules 
can't be defined by ACLs (eg. access from 8.00 to 17.00 to the resource).
We do have such an access layer in our legacy framework and there
we also have the possibility to define the access rules declarative (like
ACLs) but also by somtehing like the proposed ResourceAccessController
services. 

I do share Justins fear, that we get poor performance if we do have to
call the JCR provider twice to once get to know if the user has access and
once to get the resource. But maybe the JCR resource provider can cache 
the resource from the first call and the performance ist fine.
I think we should not design a general architecture for access controlling
an make the JCR a special case. I would prefer a "clean" design with only
one service interface for access controlling (without exceptions).
The approach where the ResourceProvider implements it's own access 
control mechanism avoids the possibility for a special ResourceAccessController
to overwrite some access roles (like the example above with access
between 8.00 and 17.00). Plus, it would be less understandable than the
clean approach with just one entry point where access controlling is 
taking place.

What I missed in the discussion so far is, that the proposed mechanisms 
are only usable for read. I think a general access controller mechanism in
Sling should provide access controlling for read, write, modify and delete.
With such an architecture it would be much easier to control security aspects
of the application. 

best regards
mike


> -Original Message-
> From: justinedel...@gmail.com [mailto:justinedel...@gmail.com] On Behalf Of 
> Justin
> Edelson
> Sent: Tuesday, November 15, 2011 5:24 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] Improving access control
> 
> Thanks for the clarification Julian. This makes more sense. I have two
> concerns with the variant you're describing:
> 
> 1) It does not provide a way for ResourceProvider implementers to
> provide their own access control mechanism, which is one thing I
> really liked in Carsten's original proposal.
> 2) In the case of the JCR ResourceProvider, it seems likely to lead to
> poor performance because the access control rules in the repository
> will be evaluated twice.
> 
> Justin
> 
> On Sun, Nov 13, 2011 at 1:35 PM, Julian Sedding  wrote:
> > Hi Justin
> >
> > Carsten's original proposal introduced two ways to handle access
> > control: ACLAwareResourceProvider and ResourceAccessController.
> >
> > The ACLAwareResourceProvider would act just like JCR Resources are
> > currently handled, i.e. with access control already enforced by the
> > underlying storage layer. The interface would merely indicate that
> > this ResourceProvider takes care of access control by itself (and
> > should presumably bypass any ResourceAccessController services).
> >
> > ResourceAccessController would be a new concept and interface, which
> > allows different implementations as services. A
> > ResourceAccessController (presumably again) indicates whether access
> > is granted or denied.
> >
> > The variation I propose is to drop the ACLAwareResourceProvider
> > concept and implement a ResourceAccessController for JCR resources
> > instead. The implementation would grant or deny access to a resource
> > based on ACLs in Jackrabbit.
> >
> > So a request for /foo would hit the SlingMainServlet, then the
> > Authenticator. Let's assume we now have a known user, we ask any
> > ResourceAccessController services if the user is granted access. If
> > access is denied, an appropriate response is sent (e.g. 403). If
> > access is granted, the ResourceProviders will be asked for the
> > resource. If the resource is unavailable, a 404 response can be sent,
> > otherwise Sling renders the resource.
> >
> > I'm not using the term ACL, as the ResourceAccessController are no
> > declarative lists of access control information. They can be
> > implemented in java, and one possible implementation are ACLs.
> >
> > Does this clarify my previous comment?
> >
> > Regards
> > Julian
> >
> >
> >
> > On Sun, Nov 13, 2011 at 1:04 AM, Justin Edelson
> >  wrote:
> >> Hi Julian,
> >> I don't think I understand what you are suggesting here. Can you
> >> elaborate on what the code path would be in the case, for example, of
> >> a Bundle Resource Provider? If a bundle provides resources under, say,
> >> /mybundle, where would the ACL live and who would be responsible for
> >> evaluating it?
> >>
> >> I feel like I'm missing something obvious, so please bear with me :)
> >>
> >> Thanks,
> >> Justin
> >>
> >> On Sat, Nov 12, 2011 at 9:16 AM, Julian Sedding  wrote:
> >>> Hi Carsten
> >>>
> >>> Interesting idea. Having access control handled by services allows
> >>> implementing 

[jira] [Resolved] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Resolved) (JIRA)]

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

Felix Meschberger resolved SLING-2296.
--

Resolution: Fixed

The build failures are now fixed (thus the events are sent) and so this 
resolves this issue.

> Transient ResourceResolver bundle build failure on Linux
> 
>
> Key: SLING-2296
> URL: https://issues.apache.org/jira/browse/SLING-2296
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.1.0
>
>
> Often times I get build failures of the JCR ResourceResolver Bundle:
>   
> testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
>  expected:<3> but was:<1>
>   testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
> expected:<3> but was:<1>
> Looking and tracing the code it seems that the JcrResourceListener gets the 
> JCR events and handles them correctly. But the sendOsgiEvent method does not 
> actually forward the event. This is caused by the JcrResourceListener's 
> internal resource resolver not (yet ?) knowing the added or changed resource 
> and thus not being able to read it to get the resource type.
> The sendOsgiEvent method should be modified to make sure the event is sent 
> regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Commented) (JIRA)]

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

Felix Meschberger commented on SLING-2296:
--

Committed a fix in Rev. 1204886. This also makes use of the sendOsgiEvent for 
removal events and thus consolidates the generation of the OSGi Event object in 
a single method.

> Transient ResourceResolver bundle build failure on Linux
> 
>
> Key: SLING-2296
> URL: https://issues.apache.org/jira/browse/SLING-2296
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Affects Versions: JCR Resource 2.0.10
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: JCR Resource 2.1.0
>
>
> Often times I get build failures of the JCR ResourceResolver Bundle:
>   
> testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
>  expected:<3> but was:<1>
>   testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
> expected:<3> but was:<1>
> Looking and tracing the code it seems that the JcrResourceListener gets the 
> JCR events and handles them correctly. But the sendOsgiEvent method does not 
> actually forward the event. This is caused by the JcrResourceListener's 
> internal resource resolver not (yet ?) knowing the added or changed resource 
> and thus not being able to read it to get the resource type.
> The sendOsgiEvent method should be modified to make sure the event is sent 
> regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2296) Transient ResourceResolver bundle build failure on Linux

[Felix Meschberger (Created) (JIRA)]

Transient ResourceResolver bundle build failure on Linux


 Key: SLING-2296
 URL: https://issues.apache.org/jira/browse/SLING-2296
 Project: Sling
  Issue Type: Bug
  Components: JCR
Affects Versions: JCR Resource 2.0.10
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: JCR Resource 2.1.0


Often times I get build failures of the JCR ResourceResolver Bundle:

  
testDefaultWorkspace(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest):
 expected:<3> but was:<1>
  testInWs2(org.apache.sling.jcr.resource.internal.JcrResourceListenerTest): 
expected:<3> but was:<1>

Looking and tracing the code it seems that the JcrResourceListener gets the JCR 
events and handles them correctly. But the sendOsgiEvent method does not 
actually forward the event. This is caused by the JcrResourceListener's 
internal resource resolver not (yet ?) knowing the added or changed resource 
and thus not being able to read it to get the resource type.

The sendOsgiEvent method should be modified to make sure the event is sent 
regardless of whether the resource type can be resolved or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (SLING-2290) Updating a fragment with a different version but the same content does not work

[Carsten Ziegeler (Assigned) (JIRA)]

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

Carsten Ziegeler reassigned SLING-2290:
---

Assignee: Carsten Ziegeler

> Updating a fragment with a different version but the same content does not 
> work
> ---
>
> Key: SLING-2290
> URL: https://issues.apache.org/jira/browse/SLING-2290
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.2.4, JCR Installer 3.1.2
>Reporter: Konrad Windszus
>Assignee: Carsten Ziegeler
> Attachments: simplebundle-0.0.1-SNAPSHOT.jar, 
> simplebundle-0.0.2-SNAPSHOT.jar, simplebundle-0.0.2-SNAPSHOT.jar
>
>
> If you update a bundle through a JCR package, it is only updated in Apache 
> Felix if the actual content has changed. It is not enough to have the version 
> number changed. This is a problem, because usually in multimodule maven 
> builds I increase the version for all contained bundles although they might 
> not have changed in that release. Unfortunately the new version is not 
> deployed, therefore the Webconsole still shows the old version.
> The same problem applies to Bundle Fragments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SLING-2290) Updating a fragment with a different version but the same content does not work

[Carsten Ziegeler (Updated) (JIRA)]

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

Carsten Ziegeler updated SLING-2290:


Summary: Updating a fragment with a different version but the same content 
does not work  (was: Updating a bundle with a different version but the same 
content does not work)

Changing title

> Updating a fragment with a different version but the same content does not 
> work
> ---
>
> Key: SLING-2290
> URL: https://issues.apache.org/jira/browse/SLING-2290
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.2.4, JCR Installer 3.1.2
>Reporter: Konrad Windszus
> Attachments: simplebundle-0.0.1-SNAPSHOT.jar, 
> simplebundle-0.0.2-SNAPSHOT.jar, simplebundle-0.0.2-SNAPSHOT.jar
>
>
> If you update a bundle through a JCR package, it is only updated in Apache 
> Felix if the actual content has changed. It is not enough to have the version 
> number changed. This is a problem, because usually in multimodule maven 
> builds I increase the version for all contained bundles although they might 
> not have changed in that release. Unfortunately the new version is not 
> deployed, therefore the Webconsole still shows the old version.
> The same problem applies to Bundle Fragments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (SLING-2203) Allow for better configuration of sling home folder

[Carsten Ziegeler (Assigned) (JIRA)]

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

Carsten Ziegeler reassigned SLING-2203:
---

Assignee: Carsten Ziegeler  (was: Felix Meschberger)

> Allow for better configuration of sling home folder
> ---
>
> Key: SLING-2203
> URL: https://issues.apache.org/jira/browse/SLING-2203
> Project: Sling
>  Issue Type: Improvement
>  Components: Launchpad
>Affects Versions: Launchpad Base 2.3.0
>Reporter: Felix Meschberger
>Assignee: Carsten Ziegeler
> Fix For: Launchpad Base 2.4.0
>
>
> Currently a few files and folders in the ${sling.home} folder can be more 
> freely located than others:
>   * The org.apache.sling.launchpad.base.jar file is expected inside 
> ${sling.home}, hardcoded
>   * The sling.properties file is expected inside ${sling.home}, hardcoded
>   * The start folder containing initial bundles to install is expected inside 
> ${sling.home}, hardcoded
>   * The Felix framework cache location is configured by the 
> org.osgi.framework.storage property
>   * The location of Configuration Admin configuration is configured by the 
> felix.cm.dir property
>   * The location for File Installer (of the OSGi Install facility) is 
> configured by the sling.installer.dir property
> To have more flexibility, two new properties should be added:
> * sling.properties (default: ${sling.home}/sling.properties) -- Provides the 
> path and name of the sling.properties file contains the configurable 
> properties used for starting Sling and then becoming Framework properties 
> accessible with the BundleContext.getProperty(String) method. This property 
> itself is also available as a Framework property and will be set to the 
> default value by the Sling Launcher if not already set. The property must not 
> contain a reference to another property but if it is not an absolute path, it 
> is resolved against ${sling.home}.
> * sling.launchpad (default: ${sling.home}) Defines the location of Sling 
> Launchpad related files and folders. At the moment this is the location of 
> the org.apache.sling.launchpad.base.jar library which provides the OSGi 
> Framework and the startup folder which takes bundles to install on framework 
> startup. The property must not contain a reference to another property but if 
> it is not an absolute path, it is resolved against ${sling.home}.
> The defaults are defined such, that they account for backwards compatibility.
> From a little code inspection, probably the following areas have to be 
> updated:
>   * The Sling class must ensure the property values
>   * The Sling class (loadConfigProperties method) must be modified to read 
> the sling.properties file from the location indicated by the 
> ${sling.properties} property
>   * The Launcher class must be modified to look for and place the launcher 
> jar in the ${sling.launchpad} folder (instead of ${sling.home})
>   * The BootstrapInstaller class must be modified to expect bundles in the 
> ${sling.launchpad}/startup folder

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira