[jira] [Comment Edited] (SLING-2698) Add a minimal resource access gate

["Julian Sedding (JIRA)" <ji...@apache.org>]

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

Julian Sedding edited comment on SLING-2698 at 3/5/13 9:28 AM:
---------------------------------------------------------------

I like Carsten's idea of wrapping the ResourceResolver. This should allow to fully control the resources provided by this resolver. I presume this could be as simple as adding a ResourceResolverCustomizer interface, that can be implemented by client-code. In ResourceResolverFactoryImpl#getResourceResolverInternal() all ResourceResolverCustomizers will get given a chance to customize the ResourceResolver in service.ranking order (by decorating it, exchanging it all together, or anything else that people could come up with).

The interface could look like this:
{code:java} 
/**
 * Hook that can be implemented to intercept a ResourceResolver just after its
 * creation in order to do any modifications on it, e.g. decorating it with additional
 * behavior.
 */
public interface ResourceResolverCustomizer {
    /**
     * This method allows modifying, decorating or exchanging a resource-resolver
     * immediately after its creation. It is guaranteed that the {@code ResourceResolver}
     * provided as an argument has not been used yet.
     */
    public ResourceResolver customize(ResourceResolver resolver);
}
{code}

Given such a hook, the ResourceAccessGate could implement this hook and live in its own bundle, thus decoupling it from the resourceresolver bundle and its release-cycle.

In addition, a decorator-based approach probably allows for relatively easy mocking and unit-testing.

I implemented a generic ResourceResolverWrapper a while ago, which makes sure all its Resources are also wrapped. The implementation lacks some new methods, but might help to implement such an approach. I'll attach it in case it's useful.

Regarding the regexps, my concerns stem from a recent negative experience (different software, similar scenario). I agree that regexps may be useful and should be allowed in implementations of ResourceAccessGate. I would try, however, to avoid using regexps in the ResourceAccessGateHandler. This should allow efficient preselection of relevant ResourceAccessGates and still allows for arbitrary flexibility.

Regarding unwrapping the Resource intentionally, I agree that that's a non-issue. A developer may just as well retrieve an administrative ResourceResolver, if so inclined. With the current ResourceDecorator approach, we might run into situations like SLING-2739, however, if we can decorate the ResourceResolver, we should have better control.
                
      was (Author: jsedding):
    I like Carsten's idea of wrapping the ResourceResolver. This should allow to fully control the resources provided by this resolver. I presume this could be as simple as adding a ResourceResolverCustomizer interface, that can be implemented by client-code. In ResourceResolverFactoryImpl#getResourceResolverInternal() all ResourceResolverCustomizers will get given a chance to customize the ResourceResolver in service.ranking order (by decorating it, exchanging it all together, or anything else that people could come up with).

The interface could look like this:
'''
/**
 * Hook that can be implemented to intercept a ResourceResolver just after its
 * creation in order to do any modifications on it, e.g. decorating it with additional
 * behavior.
 */
public interface ResourceResolverCustomizer {
    /**
     * This method allows modifying, decorating or exchanging a resource-resolver
     * immediately after its creation. It is guaranteed that the {@code ResourceResolver}
     * provided as an argument has not been used yet.
     */
    public ResourceResolver customize(ResourceResolver resolver);
}
'''

Given such a hook, the ResourceAccessGate could implement this hook and live in its own bundle, thus decoupling it from the resourceresolver bundle and its release-cycle.

In addition, a decorator-based approach probably allows for relatively easy mocking and unit-testing.

I implemented a generic ResourceResolverWrapper a while ago, which makes sure all its Resources are also wrapped. The implementation lacks some new methods, but might help to implement such an approach. I'll attach it in case it's useful.

Regarding the regexps, my concerns stem from a recent negative experience (different software, similar scenario). I agree that regexps may be useful and should be allowed in implementations of ResourceAccessGate. I would try, however, to avoid using regexps in the ResourceAccessGateHandler. This should allow efficient preselection of relevant ResourceAccessGates and still allows for arbitrary flexibility.

Regarding unwrapping the Resource intentionally, I agree that that's a non-issue. A developer may just as well retrieve an administrative ResourceResolver, if so inclined. With the current ResourceDecorator approach, we might run into situations like SLING-2739, however, if we can decorate the ResourceResolver, we should have better control.
                  
> Add a minimal resource access gate
> ----------------------------------
>
>                 Key: SLING-2698
>                 URL: https://issues.apache.org/jira/browse/SLING-2698
>             Project: Sling
>          Issue Type: New Feature
>          Components: ResourceResolver
>            Reporter: Mike Müller
>            Assignee: Mike Müller
>             Fix For: Resource Resolver 1.1.0
>
>         Attachments: resource-resolver-wrapper.patch
>
>
> Adding a minmal resource access gate as discussed in [1].
> First step is to define the API interface and a minimal implementation which allows to define READ access (rest of CRUD can follow later)
> [1] http://markmail.org/thread/4ctczoiy533tquyl

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira