Refining the authentication process
Hi all, Currently the authentication process is kind of broken and should be fixed. See the concept page "Authentication Initiation" [1]. In essence the problem is, that authentication can only be initiated by visiting special authentication pages explicitly or by being redirected. Servlets and scripts (e.g. a 404/NOT FOUND error handler) cannot easily initiate authentication without knowing the URL to the login page. I propose to create a new service interface Authenticator, which is implemented by the existing SlingAuthenticator class (both in the o.a.sling.engine bundle). This interface has a requestAuthentication method, which may be used to initiate authentication from within servlets or scripts and have the requestAuthentication method of the appropriate handler be called for the current request. In addition, the sling:authRequestLogin parameter supported by the HTTP Basic authentication handler should actually be handled by the SlingAuthenticator. This enables any client to initiate authentication by just specifying this parameter and have the SlingAuthenticator call the requestAuthentication method of the appropriate handler be called for the request. This makes the whole authentication initiation process much more transparent and allows for better alignment of login forms to the authentication handlers they are intended to work with. WDYT ? Regards Felix [1] http://cwiki.apache.org/SLING/authentication-initiation.html
[jira] Closed: (SLING-935) AbstractSlingRepository.startRepository() may not dispose off repository
[ https://issues.apache.org/jira/browse/SLING-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-935. --- Resolution: Fixed Ensure the repository is disposed off and the field is cleared if pingRepository succeeds but pingAndCheck fails in startRepository in Rev. 767390. Also add some more DEBUG logging around starting the repository. > AbstractSlingRepository.startRepository() may not dispose off repository > > > Key: SLING-935 > URL: https://issues.apache.org/jira/browse/SLING-935 > Project: Sling > Issue Type: Bug > Components: JCR >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Base 2.0.4 > > > The AbstractSlingRepository.startRepository starts (or accesses) the > repository and does two checks: pingRepository to see whether the repository > replies and pingAndCheck to see whether the repository replies and a session > may be acquired. In certain situations, the pinRepository method may return > true, while the pingAndCheck method returns false. This causes the acquired > repository not not be disposed off by calling the disposeRepository method > (only the field is nulled out). > This may result in an unusable repository setup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-934) AbstractSlingRepository.java unbindLog() sets method scoped log to null
[
https://issues.apache.org/jira/browse/SLING-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved SLING-934.
-
Resolution: Fixed
Fixed in Rev. 767390.
Please close this issue, if this is ok for you. Thanks.
> AbstractSlingRepository.java unbindLog() sets method scoped log to null
> ---
>
> Key: SLING-934
> URL: https://issues.apache.org/jira/browse/SLING-934
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Stuart Freeman
>Assignee: Felix Meschberger
> Fix For: JCR Base 2.0.4
>
>
> bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository.java
> contains the following snippet:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> log = null;
> }
> }
> That sets the method scoped log to null, not the instance scoped this.log. I
> beleive it should look like:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> this.log = null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-935) AbstractSlingRepository.startRepository() may not dispose off repository
AbstractSlingRepository.startRepository() may not dispose off repository Key: SLING-935 URL: https://issues.apache.org/jira/browse/SLING-935 Project: Sling Issue Type: Bug Components: JCR Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Base 2.0.4 The AbstractSlingRepository.startRepository starts (or accesses) the repository and does two checks: pingRepository to see whether the repository replies and pingAndCheck to see whether the repository replies and a session may be acquired. In certain situations, the pinRepository method may return true, while the pingAndCheck method returns false. This causes the acquired repository not not be disposed off by calling the disposeRepository method (only the field is nulled out). This may result in an unusable repository setup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-934) AbstractSlingRepository.java unbindLog() sets method scoped log to null
[
https://issues.apache.org/jira/browse/SLING-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-934:
Fix Version/s: JCR Base 2.0.4
> AbstractSlingRepository.java unbindLog() sets method scoped log to null
> ---
>
> Key: SLING-934
> URL: https://issues.apache.org/jira/browse/SLING-934
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Stuart Freeman
>Assignee: Felix Meschberger
> Fix For: JCR Base 2.0.4
>
>
> bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository.java
> contains the following snippet:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> log = null;
> }
> }
> That sets the method scoped log to null, not the instance scoped this.log. I
> beleive it should look like:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> this.log = null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-934) AbstractSlingRepository.java unbindLog() sets method scoped log to null
[
https://issues.apache.org/jira/browse/SLING-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701385#action_12701385
]
Felix Meschberger commented on SLING-934:
-
Correct. Thanks for reporting.
> AbstractSlingRepository.java unbindLog() sets method scoped log to null
> ---
>
> Key: SLING-934
> URL: https://issues.apache.org/jira/browse/SLING-934
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Stuart Freeman
>Assignee: Felix Meschberger
>
> bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository.java
> contains the following snippet:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> log = null;
> }
> }
> That sets the method scoped log to null, not the instance scoped this.log. I
> beleive it should look like:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> this.log = null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-934) AbstractSlingRepository.java unbindLog() sets method scoped log to null
[
https://issues.apache.org/jira/browse/SLING-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger reassigned SLING-934:
---
Assignee: Felix Meschberger
> AbstractSlingRepository.java unbindLog() sets method scoped log to null
> ---
>
> Key: SLING-934
> URL: https://issues.apache.org/jira/browse/SLING-934
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Reporter: Stuart Freeman
>Assignee: Felix Meschberger
>
> bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository.java
> contains the following snippet:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> log = null;
> }
> }
> That sets the method scoped log to null, not the instance scoped this.log. I
> beleive it should look like:
> protected void unbindLog(LogService log) {
> if (this.log == log) {
> this.log = null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-934) AbstractSlingRepository.java unbindLog() sets method scoped log to null
AbstractSlingRepository.java unbindLog() sets method scoped log to null
---
Key: SLING-934
URL: https://issues.apache.org/jira/browse/SLING-934
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Stuart Freeman
bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository.java
contains the following snippet:
protected void unbindLog(LogService log) {
if (this.log == log) {
log = null;
}
}
That sets the method scoped log to null, not the instance scoped this.log. I
beleive it should look like:
protected void unbindLog(LogService log) {
if (this.log == log) {
this.log = null;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: UserManager
To be honest I hadn't spotted that subtlety,
from Sling's use of the core UserManager, users are created under the
location for the current user, and the same goes for the group
definition file resulting in a tree of who created which user or group.
So provided one user isn't used to create to many users or groups
there is more scalability.
This does however make the location of a user non predictable, and
doesn't really solve the initial problem where one user creates all
the other users, as might happen with self or auto registration.
Perhaps thats a good thing anyway, since IMHO an app shouldn't guess
where data might be stored.
If Sling used the intermediatePath version of the method, then the
user manager servlets on create would be able generate an initial
hashed path, however it would still live under the users subtree
eg
String pathHash = StringUtils.pathHashString("ieb");
// pathHash is 3e/fe
userManager.createUser("ieb","pass",principal,pathHash);
might result in
/rep:security/rep:authorizables/rep:users/3e/fe/ieb
for self registration or auto registration.
and
/rep:security/rep:authorizables/rep:users/od/ae/admin/3e/fe/ieb
if the admin user created ieb.
Does this have impact elsewhere ? Like adding members to groups or is
there an assumption that the UI will discover users and/or work from a
list of found users ?
Ian
(BTW, I am still very much learning how this part of Sling and JR
works).
On 21 Apr 2009, at 19:11, Marc Speck wrote:
Did you see UserManager.createUser(String userID, String password,
Principal
principal, String intermediatePath) ? The userManager creates the
nodes
according to the intermediatePath and places the new user below
those nodes.
However, it seems that currently the root is
/rep:security/rep:authorizables/rep:users/admin and not
/rep:security/rep:authorizables/rep:users/ as I'd have expected.
There is also an anlog method for groups.
Marc
Re: UserManager
Hi Ian On Tue, Apr 21, 2009 at 7:45 PM, Ian Boston wrote: > I have been looking at user manager and the way in which it stores users in > the JCR. > > Is there a suitable place to perform a storage abstraction. At the moment > users all go into 1 folder, and this might be ok for up to a few 1000. But > we typically have 25K to 200K users on current installations, and are > expecting in the region of 4-5M users on future installations. Did you see UserManager.createUser(String userID, String password, Principal principal, String intermediatePath) ? The userManager creates the nodes according to the intermediatePath and places the new user below those nodes. However, it seems that currently the root is /rep:security/rep:authorizables/rep:users/admin and not /rep:security/rep:authorizables/rep:users/ as I'd have expected. There is also an anlog method for groups. Marc > > > I can see that this is all in the UserManagerImpl which is really part of > jackrabbit core, so perhaps I should ask there, but since the UI may be > accessing the URL's directly I was hoping there was a suitable place to put > a hashed tree in so the UI didnt have to adjust the URL's (like the webdav > resource locator classes) > > Ian >
UserManager
I have been looking at user manager and the way in which it stores users in the JCR. Is there a suitable place to perform a storage abstraction. At the moment users all go into 1 folder, and this might be ok for up to a few 1000. But we typically have 25K to 200K users on current installations, and are expecting in the region of 4-5M users on future installations. I can see that this is all in the UserManagerImpl which is really part of jackrabbit core, so perhaps I should ask there, but since the UI may be accessing the URL's directly I was hoping there was a suitable place to put a hashed tree in so the UI didnt have to adjust the URL's (like the webdav resource locator classes) Ian
FYI: wiki includes gliffy plugin for diagrams
Hi, Just found out that our confluence wiki includes the gliffy plugin for diagrams - created a test page at http://cwiki.apache.org/confluence/display/SLING/Testing%20gliffy%20diagrams if you want to play with it. (Didn't test if such diagrams would make it to the website though) -Bertrand
Re: WebDav & Node properties
If SlingSimpleWebDavServlet gets the config defined under https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp/src/main/webapp/WEB-INF/config.xmlthe propertyhandlers should do what you need (autoexport of properties). Since I don't have a project setup here to look what's configured in the default Slinginstance.. could anyone do this please!? :) This is just how I understood the PropertyManager-Function by looking into svn-sources for some minutes, so I might have missunderstood this feature. Regards, Dominik On Tue, Apr 21, 2009 at 2:22 PM, Julian Reschke wrote: > Bertrand Delacretaz wrote: > >> On Mon, Apr 20, 2009 at 5:45 PM, Carl Hall wrote: >> >>> Are node properties viewable/changeable through webdav access to a JCR >>> repo? >>> >> >> Not AFAIK, WebDAV is about files...I *think* there's an enhanced >> WebDAV component in Jackrabbit that allows for some additional JCR >> remoting, can anyone confirm? >> > > Hu? > > WebDAV is about properties as well, and I'm pretty sure the Jackrabbit > WebDAV servlet supports this... > > BR, Julian >
Re: WebDav & Node properties
Bertrand Delacretaz wrote: On Mon, Apr 20, 2009 at 5:45 PM, Carl Hall wrote: Are node properties viewable/changeable through webdav access to a JCR repo? Not AFAIK, WebDAV is about files...I *think* there's an enhanced WebDAV component in Jackrabbit that allows for some additional JCR remoting, can anyone confirm? Hu? WebDAV is about properties as well, and I'm pretty sure the Jackrabbit WebDAV servlet supports this... BR, Julian
Re: WebDav & Node properties
On Tue, Apr 21, 2009 at 10:17 AM, Bertrand Delacretaz wrote: > On Mon, Apr 20, 2009 at 5:45 PM, Carl Hall wrote: >> Are node properties viewable/changeable through webdav access to a JCR repo? > > Not AFAIK, WebDAV is about files...I *think* there's an enhanced > WebDAV component in Jackrabbit that allows for some additional JCR > remoting, can anyone confirm? Yes, see http://jackrabbit.apache.org/jackrabbit-jcr-server.html or ask on the jackrabbit users list. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: What are the best practices developing bundles for Sling in Eclipse?
Hi Mike, On Mon, Apr 20, 2009 at 9:31 PM, Mike Müller wrote: > ...I tried your setup and it doesn't feel (as it seems on a first view) that > unproductive Sure, it kind of works ;-) > ...You haven't to turn off the Java Builder needfully. Let it turned > on, you get all the compiling warnings and errors as usual I *think* I started turning that off because I was losing track of what was compiling what in my target folder. But I might try turning on again, you're right. -Bertrand
Re: WebDav & Node properties
On Mon, Apr 20, 2009 at 5:45 PM, Carl Hall wrote: > Are node properties viewable/changeable through webdav access to a JCR repo? Not AFAIK, WebDAV is about files...I *think* there's an enhanced WebDAV component in Jackrabbit that allows for some additional JCR remoting, can anyone confirm? -Bertrand
