You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2010/08/19 15:20:35 UTC
[jira] Created: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Implement WebConsoleSecurityProvider using Auth Core
----------------------------------------------------
Key: SLING-1670
URL: https://issues.apache.org/jira/browse/SLING-1670
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Felix Meschberger
Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-1670:
-------------------------------------
Fix Version/s: Extensions Web Console Security Provider 1.0.0
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Extensions Web Console Security Provider 1.0.0
>
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900629#action_12900629 ]
Felix Meschberger commented on SLING-1670:
------------------------------------------
Committed first version in Rev. 987396.
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900608#action_12900608 ]
Felix Meschberger commented on SLING-1670:
------------------------------------------
Actually the API was introduced in Web Console 3.1 and it is limited in that the service is provided with user name and password and has to return an identifying object. Internally the Web Console still uses HTTP Basic authentication.
Thus the solution for Sling is to use the provided user name and password to login to repository and apply a few checks.
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Why does currentNode.getNodes() not return a NodeIterator?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 19.08.2010 16:10, Clemens Wyss wrote:
> you say getNodes() returns properties?
No, getNodes() returns a JavaScript object whose properties (in terms of
JavaScript) are the childe nodes, where the index (label, key) is the
child node name and the value is the child node.
>
> AND currentNode doesn't "provide" its child nodes?
>
> Is currentNode at all an instance of javax.jcr.Node?
In JavaScript currentNode is an instance of JavaScript wrapper for
javax.jcr.Node but node javax.jcr.Node.
Regards
Felix
>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Thursday, August 19, 2010 4:01 PM
>> To: dev@sling.apache.org
>> Subject: Re: Why does currentNode.getNodes() not return a
>> NodeIterator?
>>
>>
>> Hi Clemens,
>>
>> This is a problem of an early decision to convert the result of a
>> getNodes() call into a JavaScript object where the returned nodes are
>> properties.
>>
>> Thus the result is not a NodeIterator, unfortunately.
>>
>> Regards
>> Felix
>>
>> On 19.08.2010 15:37, Clemens Wyss wrote:
>>> my esp script starts as follows:
>>> if (currentNode)
>>> {
>>> var nodes = currentNode.getNodes( );
>>>
>>> var size = nodes.getSize();
>>> ...
>>>
>>> I keep getting:
>>> Uncaught SlingException org.mozilla.javascript.EcmaError:
>> TypeError: getSize is not a function, it is
>> org.mozilla.javascript.Undefined
>>>
>>> what am I missing? I know I shouldn't be usign currentNode
>> at all, but after all currentNode is not null and the doc
>> says that getNodes() always returns a NodeIterator...
>>
RE: Why does currentNode.getNodes() not return a NodeIterator?
Posted by Clemens Wyss <cl...@mysign.ch>.
you say getNodes() returns properties?
AND currentNode doesn't "provide" its child nodes?
Is currentNode at all an instance of javax.jcr.Node?
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Thursday, August 19, 2010 4:01 PM
> To: dev@sling.apache.org
> Subject: Re: Why does currentNode.getNodes() not return a
> NodeIterator?
>
>
> Hi Clemens,
>
> This is a problem of an early decision to convert the result of a
> getNodes() call into a JavaScript object where the returned nodes are
> properties.
>
> Thus the result is not a NodeIterator, unfortunately.
>
> Regards
> Felix
>
> On 19.08.2010 15:37, Clemens Wyss wrote:
> > my esp script starts as follows:
> > if (currentNode)
> > {
> > var nodes = currentNode.getNodes( );
> >
> > var size = nodes.getSize();
> > ...
> >
> > I keep getting:
> > Uncaught SlingException org.mozilla.javascript.EcmaError:
> TypeError: getSize is not a function, it is
> org.mozilla.javascript.Undefined
> >
> > what am I missing? I know I shouldn't be usign currentNode
> at all, but after all currentNode is not null and the doc
> says that getNodes() always returns a NodeIterator...
>
Re: Why does currentNode.getNodes() not return a NodeIterator?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Clemens,
This is a problem of an early decision to convert the result of a
getNodes() call into a JavaScript object where the returned nodes are
properties.
Thus the result is not a NodeIterator, unfortunately.
Regards
Felix
On 19.08.2010 15:37, Clemens Wyss wrote:
> my esp script starts as follows:
> if (currentNode)
> {
> var nodes = currentNode.getNodes( );
>
> var size = nodes.getSize();
> ...
>
> I keep getting:
> Uncaught SlingException org.mozilla.javascript.EcmaError: TypeError: getSize is not a function, it is org.mozilla.javascript.Undefined
>
> what am I missing? I know I shouldn't be usign currentNode at all, but after all currentNode is not null and the doc says that getNodes() always returns a NodeIterator...
Why does currentNode.getNodes() not return a NodeIterator?
Posted by Clemens Wyss <cl...@mysign.ch>.
my esp script starts as follows:
if (currentNode)
{
var nodes = currentNode.getNodes( );
var size = nodes.getSize();
...
I keep getting:
Uncaught SlingException org.mozilla.javascript.EcmaError: TypeError: getSize is not a function, it is org.mozilla.javascript.Undefined
what am I missing? I know I shouldn't be usign currentNode at all, but after all currentNode is not null and the doc says that getNodes() always returns a NodeIterator...
[jira] Issue Comment Edited: (SLING-1670) Implement
WebConsoleSecurityProvider using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900629#action_12900629 ]
Felix Meschberger edited comment on SLING-1670 at 8/20/10 4:08 AM:
-------------------------------------------------------------------
Committed first version in Rev. 987396.
The security provider for the Apache Felix Web Console grants access to the repository based on the user name and password provided.
(1) A session is acquired for the user name and password
(2) If the user is one of a configurable set of users allowed
access, the user is granted access.
(3) Otherwise if the user is a member of one of a configurable
set of groups allowed access, the user is granted access.
If the user name and password cannot be used to login to the repository or the user is neither in the configured set of users nor a member of one of the configured groups, access is denied.
was (Author: fmeschbe):
Committed first version in Rev. 987396.
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-1670.
--------------------------------------
Resolution: Fixed
Positive feedback received. Thus added to the reactor and the Launchpad Builder bundles in Rev. 987753
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Extensions Web Console Security Provider 1.0.0
>
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1670) Implement WebConsoleSecurityProvider
using JCR Repository
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed SLING-1670.
------------------------------------
Close after release
> Implement WebConsoleSecurityProvider using JCR Repository
> ---------------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Extensions Web Console Security Provider 1.0.0
>
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-1670:
----------------------------------------
Assignee: Felix Meschberger
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1670) Implement WebConsoleSecurityProvider
using JCR Repository
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-1670:
-------------------------------------
Summary: Implement WebConsoleSecurityProvider using JCR Repository (was: Implement WebConsoleSecurityProvider using Auth Core)
Fix title to match reality
> Implement WebConsoleSecurityProvider using JCR Repository
> ---------------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Extensions Web Console Security Provider 1.0.0
>
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 20.08.2010 14:48, Clemens Wyss wrote:
> here you go:
> https://issues.apache.org/jira/browse/SLING-1672
>
> I am not yet familiar where things belong to
Absolutely no problem.
Regards
Felix
>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Friday, August 20, 2010 2:38 PM
>> To: dev@sling.apache.org
>> Subject: Re: resource.resourceResolver.listChildren only lists jcr
>> nodes?
>>
>>
>> Hi,
>>
>> On 20.08.2010 14:31, Clemens Wyss wrote:
>>>> Hmm, this looks like a strane setup.
>>> no wonder, it's from me ;-) Basically I just wanted a
>> bundle resource (to test with) and I thought this was
>> simplest way to get one.
>>>
>>>> This header setup is for initial
>>>> content not for bundle resources
>>> the overwrite/uninstall args or the path-redirection?
>>> Again: resolving seems to work, but not enlisting.
>>>
>>>> This might be a bug in the bundle resource provider.
>>> have you got enough info's to track this down?
>>
>> Yes, but having a JIRA issue would help "not forgetting about
>> it" ;-) Thanks
>>
>> Regards
>> Felix
>>
>>>
>>>> -----Original Message-----
>>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>>> Sent: Friday, August 20, 2010 1:36 PM
>>>> To: dev@sling.apache.org
>>>> Subject: Re: resource.resourceResolver.listChildren only lists jcr
>>>> nodes?
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 20.08.2010 11:54, Clemens Wyss wrote:
>>>>> in my pom.xml I have:
>>>>> <Sling-Bundle-Resources>
>>>>>
>>>> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs
>>>> /sling/explorer
>>>>
>>>> Hmm, this looks like a strane setup. This header setup is
>> for initial
>>>> content not for bundle resources.
>>>>
>>>> But yes, you are right, you should be able to see the
>> "/res" resource
>>>> (synthetic) and then /res/sling, /res/sling/explorer and
>>>> everything below.
>>>>
>>>> This might be a bug in the bundle resource provider.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> </Sling-Bundle-Resources>
>>>>>
>>>>> i.e. I map /res/sling/explorer to /libs/sling/explorer. And
>>>> I can directly access the files beneath /res/sling/explorer,
>>>> e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
>>>>>
>>>>> now when I enlist on the root (/) I don't see 'res'? Should
>>>> or shouldn't I?
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>>>>> Sent: Friday, August 20, 2010 11:31 AM
>>>>>> To: dev@sling.apache.org
>>>>>> Subject: Re: resource.resourceResolver.listChildren only
>> lists jcr
>>>>>> nodes?
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> No, the listChildren method is implemented to return all
>>>>>> child resources
>>>>>> in the Resource tree, not only JCR nodes.
>>>>>>
>>>>>> And no, the ResourceResolver is not specifically wrapped.
>>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>> On 20.08.2010 11:20, Clemens Wyss wrote:
>>>>>>> in my esp-script I have the follwoing line:
>>>>>>>
>>>>>>> var childResources = request.resourceResolver.listChildren(
>>>>>> resource );
>>>>>>>
>>>>>>> To me (having explicitly definde bundle resources) it looks
>>>>>> as if this only lists jcr nodes but not all resources.
>>>>>>> Is this yet another esp limitation (of the wrapper behind
>>>>>> 'resource'), or does listChildren really only return jcr nodes?
>>>>>>>
>>>>>>> Asked the other way round:
>>>>>>> given a path, how do I enlist (in esp) all resources below
>>>>>> that path?
>>>>>>
>>>>
>>
RE: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Clemens Wyss <cl...@mysign.ch>.
here you go:
https://issues.apache.org/jira/browse/SLING-1672
I am not yet familiar where things belong to
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Friday, August 20, 2010 2:38 PM
> To: dev@sling.apache.org
> Subject: Re: resource.resourceResolver.listChildren only lists jcr
> nodes?
>
>
> Hi,
>
> On 20.08.2010 14:31, Clemens Wyss wrote:
> >> Hmm, this looks like a strane setup.
> > no wonder, it's from me ;-) Basically I just wanted a
> bundle resource (to test with) and I thought this was
> simplest way to get one.
> >
> >> This header setup is for initial
> >> content not for bundle resources
> > the overwrite/uninstall args or the path-redirection?
> > Again: resolving seems to work, but not enlisting.
> >
> >> This might be a bug in the bundle resource provider.
> > have you got enough info's to track this down?
>
> Yes, but having a JIRA issue would help "not forgetting about
> it" ;-) Thanks
>
> Regards
> Felix
>
> >
> >> -----Original Message-----
> >> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> >> Sent: Friday, August 20, 2010 1:36 PM
> >> To: dev@sling.apache.org
> >> Subject: Re: resource.resourceResolver.listChildren only lists jcr
> >> nodes?
> >>
> >>
> >> Hi,
> >>
> >>
> >> On 20.08.2010 11:54, Clemens Wyss wrote:
> >>> in my pom.xml I have:
> >>> <Sling-Bundle-Resources>
> >>>
> >> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs
> >> /sling/explorer
> >>
> >> Hmm, this looks like a strane setup. This header setup is
> for initial
> >> content not for bundle resources.
> >>
> >> But yes, you are right, you should be able to see the
> "/res" resource
> >> (synthetic) and then /res/sling, /res/sling/explorer and
> >> everything below.
> >>
> >> This might be a bug in the bundle resource provider.
> >>
> >> Regards
> >> Felix
> >>
> >>> </Sling-Bundle-Resources>
> >>>
> >>> i.e. I map /res/sling/explorer to /libs/sling/explorer. And
> >> I can directly access the files beneath /res/sling/explorer,
> >> e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
> >>>
> >>> now when I enlist on the root (/) I don't see 'res'? Should
> >> or shouldn't I?
> >>>
> >>>> -----Original Message-----
> >>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> >>>> Sent: Friday, August 20, 2010 11:31 AM
> >>>> To: dev@sling.apache.org
> >>>> Subject: Re: resource.resourceResolver.listChildren only
> lists jcr
> >>>> nodes?
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> No, the listChildren method is implemented to return all
> >>>> child resources
> >>>> in the Resource tree, not only JCR nodes.
> >>>>
> >>>> And no, the ResourceResolver is not specifically wrapped.
> >>>>
> >>>> Regards
> >>>> Felix
> >>>>
> >>>> On 20.08.2010 11:20, Clemens Wyss wrote:
> >>>>> in my esp-script I have the follwoing line:
> >>>>>
> >>>>> var childResources = request.resourceResolver.listChildren(
> >>>> resource );
> >>>>>
> >>>>> To me (having explicitly definde bundle resources) it looks
> >>>> as if this only lists jcr nodes but not all resources.
> >>>>> Is this yet another esp limitation (of the wrapper behind
> >>>> 'resource'), or does listChildren really only return jcr nodes?
> >>>>>
> >>>>> Asked the other way round:
> >>>>> given a path, how do I enlist (in esp) all resources below
> >>>> that path?
> >>>>
> >>
>
Re: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 20.08.2010 14:31, Clemens Wyss wrote:
>> Hmm, this looks like a strane setup.
> no wonder, it's from me ;-) Basically I just wanted a bundle resource (to test with) and I thought this was simplest way to get one.
>
>> This header setup is for initial
>> content not for bundle resources
> the overwrite/uninstall args or the path-redirection?
> Again: resolving seems to work, but not enlisting.
>
>> This might be a bug in the bundle resource provider.
> have you got enough info's to track this down?
Yes, but having a JIRA issue would help "not forgetting about it" ;-) Thanks
Regards
Felix
>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Friday, August 20, 2010 1:36 PM
>> To: dev@sling.apache.org
>> Subject: Re: resource.resourceResolver.listChildren only lists jcr
>> nodes?
>>
>>
>> Hi,
>>
>>
>> On 20.08.2010 11:54, Clemens Wyss wrote:
>>> in my pom.xml I have:
>>> <Sling-Bundle-Resources>
>>>
>> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs
>> /sling/explorer
>>
>> Hmm, this looks like a strane setup. This header setup is for initial
>> content not for bundle resources.
>>
>> But yes, you are right, you should be able to see the "/res" resource
>> (synthetic) and then /res/sling, /res/sling/explorer and
>> everything below.
>>
>> This might be a bug in the bundle resource provider.
>>
>> Regards
>> Felix
>>
>>> </Sling-Bundle-Resources>
>>>
>>> i.e. I map /res/sling/explorer to /libs/sling/explorer. And
>> I can directly access the files beneath /res/sling/explorer,
>> e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
>>>
>>> now when I enlist on the root (/) I don't see 'res'? Should
>> or shouldn't I?
>>>
>>>> -----Original Message-----
>>>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>>>> Sent: Friday, August 20, 2010 11:31 AM
>>>> To: dev@sling.apache.org
>>>> Subject: Re: resource.resourceResolver.listChildren only lists jcr
>>>> nodes?
>>>>
>>>>
>>>> Hi,
>>>>
>>>> No, the listChildren method is implemented to return all
>>>> child resources
>>>> in the Resource tree, not only JCR nodes.
>>>>
>>>> And no, the ResourceResolver is not specifically wrapped.
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 20.08.2010 11:20, Clemens Wyss wrote:
>>>>> in my esp-script I have the follwoing line:
>>>>>
>>>>> var childResources = request.resourceResolver.listChildren(
>>>> resource );
>>>>>
>>>>> To me (having explicitly definde bundle resources) it looks
>>>> as if this only lists jcr nodes but not all resources.
>>>>> Is this yet another esp limitation (of the wrapper behind
>>>> 'resource'), or does listChildren really only return jcr nodes?
>>>>>
>>>>> Asked the other way round:
>>>>> given a path, how do I enlist (in esp) all resources below
>>>> that path?
>>>>
>>
RE: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Clemens Wyss <cl...@mysign.ch>.
> Hmm, this looks like a strane setup.
no wonder, it's from me ;-) Basically I just wanted a bundle resource (to test with) and I thought this was simplest way to get one.
> This header setup is for initial
> content not for bundle resources
the overwrite/uninstall args or the path-redirection?
Again: resolving seems to work, but not enlisting.
> This might be a bug in the bundle resource provider.
have you got enough info's to track this down?
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Friday, August 20, 2010 1:36 PM
> To: dev@sling.apache.org
> Subject: Re: resource.resourceResolver.listChildren only lists jcr
> nodes?
>
>
> Hi,
>
>
> On 20.08.2010 11:54, Clemens Wyss wrote:
> > in my pom.xml I have:
> > <Sling-Bundle-Resources>
> >
> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs
> /sling/explorer
>
> Hmm, this looks like a strane setup. This header setup is for initial
> content not for bundle resources.
>
> But yes, you are right, you should be able to see the "/res" resource
> (synthetic) and then /res/sling, /res/sling/explorer and
> everything below.
>
> This might be a bug in the bundle resource provider.
>
> Regards
> Felix
>
> > </Sling-Bundle-Resources>
> >
> > i.e. I map /res/sling/explorer to /libs/sling/explorer. And
> I can directly access the files beneath /res/sling/explorer,
> e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
> >
> > now when I enlist on the root (/) I don't see 'res'? Should
> or shouldn't I?
> >
> >> -----Original Message-----
> >> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> >> Sent: Friday, August 20, 2010 11:31 AM
> >> To: dev@sling.apache.org
> >> Subject: Re: resource.resourceResolver.listChildren only lists jcr
> >> nodes?
> >>
> >>
> >> Hi,
> >>
> >> No, the listChildren method is implemented to return all
> >> child resources
> >> in the Resource tree, not only JCR nodes.
> >>
> >> And no, the ResourceResolver is not specifically wrapped.
> >>
> >> Regards
> >> Felix
> >>
> >> On 20.08.2010 11:20, Clemens Wyss wrote:
> >>> in my esp-script I have the follwoing line:
> >>>
> >>> var childResources = request.resourceResolver.listChildren(
> >> resource );
> >>>
> >>> To me (having explicitly definde bundle resources) it looks
> >> as if this only lists jcr nodes but not all resources.
> >>> Is this yet another esp limitation (of the wrapper behind
> >> 'resource'), or does listChildren really only return jcr nodes?
> >>>
> >>> Asked the other way round:
> >>> given a path, how do I enlist (in esp) all resources below
> >> that path?
> >>
>
Re: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 20.08.2010 11:54, Clemens Wyss wrote:
> in my pom.xml I have:
> <Sling-Bundle-Resources>
> /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer
Hmm, this looks like a strane setup. This header setup is for initial
content not for bundle resources.
But yes, you are right, you should be able to see the "/res" resource
(synthetic) and then /res/sling, /res/sling/explorer and everything below.
This might be a bug in the bundle resource provider.
Regards
Felix
> </Sling-Bundle-Resources>
>
> i.e. I map /res/sling/explorer to /libs/sling/explorer. And I can directly access the files beneath /res/sling/explorer, e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
>
> now when I enlist on the root (/) I don't see 'res'? Should or shouldn't I?
>
>> -----Original Message-----
>> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
>> Sent: Friday, August 20, 2010 11:31 AM
>> To: dev@sling.apache.org
>> Subject: Re: resource.resourceResolver.listChildren only lists jcr
>> nodes?
>>
>>
>> Hi,
>>
>> No, the listChildren method is implemented to return all
>> child resources
>> in the Resource tree, not only JCR nodes.
>>
>> And no, the ResourceResolver is not specifically wrapped.
>>
>> Regards
>> Felix
>>
>> On 20.08.2010 11:20, Clemens Wyss wrote:
>>> in my esp-script I have the follwoing line:
>>>
>>> var childResources = request.resourceResolver.listChildren(
>> resource );
>>>
>>> To me (having explicitly definde bundle resources) it looks
>> as if this only lists jcr nodes but not all resources.
>>> Is this yet another esp limitation (of the wrapper behind
>> 'resource'), or does listChildren really only return jcr nodes?
>>>
>>> Asked the other way round:
>>> given a path, how do I enlist (in esp) all resources below
>> that path?
>>
RE: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Clemens Wyss <cl...@mysign.ch>.
in my pom.xml I have:
<Sling-Bundle-Resources>
/res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer
</Sling-Bundle-Resources>
i.e. I map /res/sling/explorer to /libs/sling/explorer. And I can directly access the files beneath /res/sling/explorer, e.g. http://localhost:8080/res/sling/explorer/css/explorer.css
now when I enlist on the root (/) I don't see 'res'? Should or shouldn't I?
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@gmail.com]
> Sent: Friday, August 20, 2010 11:31 AM
> To: dev@sling.apache.org
> Subject: Re: resource.resourceResolver.listChildren only lists jcr
> nodes?
>
>
> Hi,
>
> No, the listChildren method is implemented to return all
> child resources
> in the Resource tree, not only JCR nodes.
>
> And no, the ResourceResolver is not specifically wrapped.
>
> Regards
> Felix
>
> On 20.08.2010 11:20, Clemens Wyss wrote:
> > in my esp-script I have the follwoing line:
> >
> > var childResources = request.resourceResolver.listChildren(
> resource );
> >
> > To me (having explicitly definde bundle resources) it looks
> as if this only lists jcr nodes but not all resources.
> > Is this yet another esp limitation (of the wrapper behind
> 'resource'), or does listChildren really only return jcr nodes?
> >
> > Asked the other way round:
> > given a path, how do I enlist (in esp) all resources below
> that path?
>
Re: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
No, the listChildren method is implemented to return all child resources
in the Resource tree, not only JCR nodes.
And no, the ResourceResolver is not specifically wrapped.
Regards
Felix
On 20.08.2010 11:20, Clemens Wyss wrote:
> in my esp-script I have the follwoing line:
>
> var childResources = request.resourceResolver.listChildren( resource );
>
> To me (having explicitly definde bundle resources) it looks as if this only lists jcr nodes but not all resources.
> Is this yet another esp limitation (of the wrapper behind 'resource'), or does listChildren really only return jcr nodes?
>
> Asked the other way round:
> given a path, how do I enlist (in esp) all resources below that path?
RE: resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Clemens Wyss <cl...@mysign.ch>.
there is a typo in the subject, should be:
'request.resourceResolver.listChildren only lists jcr nodes?'
> -----Original Message-----
> From: Clemens Wyss [mailto:clemensdev@mysign.ch]
> Sent: Friday, August 20, 2010 11:20 AM
> To: 'dev@sling.apache.org'
> Subject: resource.resourceResolver.listChildren only lists jcr nodes?
>
>
> in my esp-script I have the follwoing line:
>
> var childResources = request.resourceResolver.listChildren(
> resource );
>
> To me (having explicitly definde bundle resources) it looks
> as if this only lists jcr nodes but not all resources.
> Is this yet another esp limitation (of the wrapper behind
> 'resource'), or does listChildren really only return jcr nodes?
>
> Asked the other way round:
> given a path, how do I enlist (in esp) all resources below that path?
>
resource.resourceResolver.listChildren only lists jcr nodes?
Posted by Clemens Wyss <cl...@mysign.ch>.
in my esp-script I have the follwoing line:
var childResources = request.resourceResolver.listChildren( resource );
To me (having explicitly definde bundle resources) it looks as if this only lists jcr nodes but not all resources.
Is this yet another esp limitation (of the wrapper behind 'resource'), or does listChildren really only return jcr nodes?
Asked the other way round:
given a path, how do I enlist (in esp) all resources below that path?
[jira] Commented: (SLING-1670) Implement WebConsoleSecurityProvider
using Auth Core
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900632#action_12900632 ]
Felix Meschberger commented on SLING-1670:
------------------------------------------
Added some JavaDoc in Rev. 987401
Not yet adding this module to the Launchpad Builder project. Discussion pending at http://markmail.org/message/b3pzzqpcdkyez2rv
> Implement WebConsoleSecurityProvider using Auth Core
> ----------------------------------------------------
>
> Key: SLING-1670
> URL: https://issues.apache.org/jira/browse/SLING-1670
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
>
> Since Web Console 3.0 the WebConsoleSecurityProvider service interface may be implemented to provide authentication support for the web console other than the built-in HTTP Basic authentication supporting a single user.
> For Sling we should implement this service leveraging the Auth Core module to allow for versatile login mechanisms as well as authenticating against the ResourceResolverFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.