multi-workspace support in script resolution

[Justin Edelson]

Currently, although it's possible to log into different workspaces via
AuthenticationInfo (even if httpauth and formauth don't support this);
script resolution only happens against the default workspace. I don't
see any reason for this restriction - it seems to me you should resolve
scripts from the same workspace as the one resource was resolved from. WDYT?

I think I've resolved this locally (still testing), but wanted to get
some feedback before committing it.

Thanks,
Justin

Build failed in Hudson: sling-contrib-1.5 #409

[Apache Hudson Server]

See 

--
[...truncated 7059 lines...]








]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237308,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237308http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237828,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237828http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784238575,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784238575http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784239088,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingSta

Build failed in Hudson: sling-contrib-1.5 » Apache Sling Launchpad Contrib Testing #409

[Apache Hudson Server]

See 


--
[...truncated 3480 lines...]














]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237308,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237308http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237828,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237828http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apache.sling.commons.testing.integration.HttpStatusCodeException: Expected 
status code 302 for POST, got 404, 
URL=http://localhost:47117/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784238575,
 Content=[


Error 404 

HTTP ERROR: 404NOT_FOUND
RequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784238575http://jetty.mortbay.org/";>Powered by Jetty://  
  






















]
org.apac

Hudson build is back to stable : sling-trunk-1.5 #637

[Apache Hudson Server]

See 

Hudson build is back to stable : sling-trun k-1.5 » Apache Sling Launchpad Testing #637

[Apache Hudson Server]

See 

Hudson build is back to stable : sling-trunk-1.6 #336

[Apache Hudson Server]

See 

Hudson build is back to stable : sling-trun k-1.6 » Apache Sling Launchpad Testing #336

[Apache Hudson Server]

See 

[jira] Resolved: (SLING-1444) add an AuthenticationInfoPostProcessor service interface

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-1444.
---

Resolution: Fixed

> add an AuthenticationInfoPostProcessor service interface
> 
>
> Key: SLING-1444
> URL: https://issues.apache.org/jira/browse/SLING-1444
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> I need to be able to modify the AuthenticationInfo object (to inject the 
> Workspace) separately from how the user's credentials were retrieved. This 
> interface would allow this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SLING-1444) add an AuthenticationInfoPostProcessor service interface

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-1444:
---

done in r923990 and r923994. documented on wiki.

> add an AuthenticationInfoPostProcessor service interface
> 
>
> Key: SLING-1444
> URL: https://issues.apache.org/jira/browse/SLING-1444
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> I need to be able to modify the AuthenticationInfo object (to inject the 
> Workspace) separately from how the user's credentials were retrieved. This 
> interface would allow this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-1445:
---

done in r923991 and added to Authentication page on wiki

> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-1445.
---

Resolution: Fixed

> store the AuthenticationInfo object in a request attribute
> --
>
> Key: SLING-1445
> URL: https://issues.apache.org/jira/browse/SLING-1445
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> called org.apache.sling.commons.auth.spi.AuthenticationInfo

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SLING-1444) add an AuthenticationInfoPostProcessor service interface

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-1444:
--

Component/s: Commons

> add an AuthenticationInfoPostProcessor service interface
> 
>
> Key: SLING-1444
> URL: https://issues.apache.org/jira/browse/SLING-1444
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Commons Auth 1.0.0
>
>
> I need to be able to modify the AuthenticationInfo object (to inject the 
> Workspace) separately from how the user's credentials were retrieved. This 
> interface would allow this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SLING-1445) store the AuthenticationInfo object in a request attribute

[Justin Edelson (JIRA)]

store the AuthenticationInfo object in a request attribute
--

 Key: SLING-1445
 URL: https://issues.apache.org/jira/browse/SLING-1445
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Reporter: Justin Edelson
Assignee: Justin Edelson
 Fix For: Commons Auth 1.0.0


called org.apache.sling.commons.auth.spi.AuthenticationInfo

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SLING-1444) add an AuthenticationInfoPostProcessor service interface

[Justin Edelson (JIRA)]

add an AuthenticationInfoPostProcessor service interface


 Key: SLING-1444
 URL: https://issues.apache.org/jira/browse/SLING-1444
 Project: Sling
  Issue Type: Improvement
Reporter: Justin Edelson
Assignee: Justin Edelson
 Fix For: Commons Auth 1.0.0


I need to be able to modify the AuthenticationInfo object (to inject the 
Workspace) separately from how the user's credentials were retrieved. This 
interface would allow this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Merging Sling API and Commons Auth API

[Justin Edelson]

On 3/16/10 4:17 PM, Mike Müller wrote:
> The case is what we discussed in [1]. There we came to the conclusion
> to use a RequestEventListener. Otherwise we have to add a lifecycle
> method like close or similar to the resource resolver or even to the
> CredentialValidator where it definitly makes no sense.
> So what's about using RequestEventListener?
To my mind, two key things need to happen:
1) Felix's patch to FELIX-1962 should be applied.
2) Felix HttpService 2.0.6 is released

But I'm not sure we should be depending on a Felix-specific interface
(ExtHttpService) in such a key piece of code. What really should be
happening is to merge Felix HttpService's ExtHttpService interface into
OSGi's HttpService interface (as HttpService version 2.0).

Justin

> An other possibility would be to insert not a plain JCR session but a
> container which contains a JCR session into the request params. The
> container then would check if there's access to the session and dispose
> it after a while. But to be honest I don't like this idea that much.
> 
> [1] http://markmail.org/message/bwgrbhwlsi5ekenn
> 
> best regards
> mike

RE: Merging Sling API and Commons Auth API

[Mike Müller]

Hi

> first of all: "hello" to all subscribers from my side :-)
>
> >interface CredentialValidator
> +1
>
> > One issue remains: disposal of the Session placed into the
> > AuthenticationInfo object by the validate method. But this can be
> > solved, I am sure ...
> isn't this session "just a session" and hence times out after
> a awhile?

In this case it's the JCR session, which is not bound to the HTTP session
does not time out automatically, you have to call session.logout.


> > Hi,
> >
> > On 14.03.2010 07:41, Mike Müller wrote:
> > >>> while working on the ResourceResolverFactory I noticed some
> > >> problems.
> > >>> We plan to let the SlingAuthenticator directly use the
> > >>> ResourceResolverFactory to authenticate. This removes all
> > >> dependencies
> > >>> to JCR from the authentication and gives us much more
> flexibility.
> > >>>
> > >>> However, currently the constants for things like user,
> > >>> password etc are
> > >>> defined in the AuthenticationInfo. In fact, these are
> > constants that
> > >>> should be defined by the ResourceResovlerFactory because
> > this is the
> > >>> service that is used for authentication.
> > >>>
> > >>> I briefly discussed this with Felix and we both came to the
> > >> conclusion
> > >>> that in fact the commons auth is not really commons :) It
> > is more an
> > >>> auth api for Sling.
> > >>>
> > >>> Therefore it seems to make sense to move the api from commons
> > >>> auth into
> > >>> the Sling API. So we have one single API to deal with. The
> > >>> implementation of the auth would stay in a separate
> > bundle (together
> > >>> with the compatibility stuff for the older engine auth).
> > >>>
> > >>> Before discussing the details like which packages to use
> > >> etc. what do
> > >>> you think in general about this?
> > >>>
> > >>> Carsten
> > >>
> > >>
> > >> +1 to move the commons auth into the Sling API in general.
> > >> But I would like to decouple the ResourceResolverFactory
> > >> completly from
> > >> Authentication. It seems that this coupling only exists
> because of
> > >> the circumstances of the JCR (to return a JcrResourceResolver the
> > >> ResourceResolverFactory needs to login into the JCR). From a more
> > >> abstract view Authentication has not certainly to be coupled with
> > >> the Factory which returns the ResourceResolver. I know
> there's the
> > >> problem with performance (depending on the implementation maybe
> > >> two logins and therefore two JCR sessions), but I think it would
> > >> be worth to stay two steps back and discuss the new
> > Authentication and
> > >> the new ResourceResovlerFactory once again. We do have now the
> > >> possibility to do that, because both concepts are new and not
> > >> released.
> > >>
> > >> best regards
> > >> mike
> > >
> > > As you probably know, this is not the first time I come up with
> > > this [1]. At the risk of being a little bit cumbersome, I really
> > > think we could design a clean API where authentication and
> > > the getting of a resource resolver is completely decoupled without
> > > loosing performance. The API doesn't tell us how we have to
> > > implement it (but is has to give us the chance to implement it
> > > without loosing performance ;-). I would propose to first define
> > > how a "brave world" API would look like and go from there.
> > > WDYT?
> > >
> > > [1] http://markmail.org/message/bwgrbhwlsi5ekenn
> >
> > My biggest concern with this was (and still is) loss of
> performance if
> > logging two login's would be required for each request. We can "fix"
> > this issue, if we defined an API to act as an intermediary, e.g.
> > something like:
> >
> >public interface CredentialValidator {
> >public AuthenticationInfo validate(
> > AuthenticationInfo credentials)
> > throws LoginException;
> >}
> >
> > This service interface would be implemented by a JCR based
> > implementation using Repository.login to valid and would be
> > used by the
> > SlingAuthenitator to validate the credentials.
> >
> > The AuthenticationInfo returned might contain the session acquired
> > during validation and be set as a request attribute. That request
> > attribute would be picked up by the SlingMainServlet to hand
> > over to the
> > ResourceResolverFactory.getResourceResolver(Map) method.
> >
> > One issue remains: disposal of the Session placed into the
> > AuthenticationInfo object by the validate method. But this can be
> > solved, I am sure ...
> >
> > More details (aka words) at [1]
> >
> > Regards
> > Felix

The case is what we discussed in [1]. There we came to the conclusion
to use a RequestEventListener. Otherwise we have to add a lifecycle
method like close or similar to the resource resolver or even to the
CredentialValidator where it definitly makes no sense.
So what's about using RequestEventListener?
An other possibility would be to insert not a plain JCR session but a
container which contains a JCR session into the request pa