RE: Merging Sling API and Commons Auth API
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 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
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
[jira] Created: (SLING-1444) add an AuthenticationInfoPostProcessor service interface
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.
[jira] Created: (SLING-1445) store the AuthenticationInfo object in a request attribute
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
[ 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] Resolved: (SLING-1445) store the AuthenticationInfo object in a request attribute
[ 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] Commented: (SLING-1445) store the AuthenticationInfo object in a request attribute
[ https://issues.apache.org/jira/browse/SLING-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Commented: (SLING-1444) add an AuthenticationInfoPostProcessor service interface
[ https://issues.apache.org/jira/browse/SLING-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] Resolved: (SLING-1444) add an AuthenticationInfoPostProcessor service interface
[ 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.
Hudson build is back to stable : sling-trunk-1.6 #336
See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/336/changes
Hudson build is back to stable : sling-trun k-1.5 » Apache Sling Launchpad Testing #637
See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/637/changes
Hudson build is back to stable : sling-trunk-1.5 #637
See http://hudson.zones.apache.org/hudson/job/sling-trunk-1.5/637/changes
Build failed in Hudson: sling-contrib-1.5 #409
See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/409/ -- [...truncated 7059 lines...] br/ br/ br/ br/ br/ /body /html ] 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=[html head meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/ titleError 404 /title /head bodyh2HTTP ERROR: 404/h2preNOT_FOUND/pre pRequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237308/ppismalla href=http://jetty.mortbay.org/;Powered by Jetty:///a/small/i/pbr/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ /body /html ] 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=[html head meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/ titleError 404 /title /head bodyh2HTTP ERROR: 404/h2preNOT_FOUND/pre pRequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784237828/ppismalla href=http://jetty.mortbay.org/;Powered by Jetty:///a/small/i/pbr/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ /body /html ] 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=[html head meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/ titleError 404 /title /head bodyh2HTTP ERROR: 404/h2preNOT_FOUND/pre pRequestURI=/org.apache.sling.launchpad.contrib-testing-4-SNAPSHOT/WaitForSlingStartup/1268784238575/ppismalla href=http://jetty.mortbay.org/;Powered by Jetty:///a/small/i/pbr/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/ br/
multi-workspace support in script resolution
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
