[jira] Resolved: (SLING-1679) Use Java Annotations instead of @scr. JavaDoc tags
[ https://issues.apache.org/jira/browse/SLING-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1679. -- Resolution: Fixed Implemented in Rev. 988014 and Rev. 988016 Use Java Annotations instead of @scr. JavaDoc tags -- Key: SLING-1679 URL: https://issues.apache.org/jira/browse/SLING-1679 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 To ease development the @scr.* JavaDoc tags currently used should be replaced by the Apache Felix SCR annotations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1678) Built-in HTTP Authentication Handler always requesting credentials
[ https://issues.apache.org/jira/browse/SLING-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1678. -- Resolution: Fixed Added support for a new configuration property auth.http to provide the values in Rev. 988016 as described. Added Metatype Service texts in Rev. 988019 Built-in HTTP Authentication Handler always requesting credentials -- Key: SLING-1678 URL: https://issues.apache.org/jira/browse/SLING-1678 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 The HTTP Authentication Handler built into the auth core module currently always sends back a 401 response if its requestCredentials method is called. There may be setups, though, where HTTP BASIC authentication must not be used at all. For such setups, it must be possible to shutdown the HTTP Authentication Handler. Thus the configuration of the HTTP Authentication Handler should be extended with an activity property with the following states: * Disabled - the HTTP Authentication Handler never returns credentials or sends a 401 response * Enabled - the HTTP Authentication Handler is fully operative returning existing credentials and sending 401 response in requestCredentials * Preemptive - the HTTP Authentication Handler returns credentials if present but does not set 401 response in the requestCredentials method -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0
+1, all checks out ok, not a great deal in the branding jars to validate :) Ian On 21 Aug 2010, at 21:56, Felix Meschberger wrote: Hi, Here are the Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0 releases. For the Web Console Branding we fixed 3 issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12314456 For the Web Console Security Provider one issue was fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315265 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-131/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 131 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
Re: [VOTE] Release Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0
+1 2010/8/22 Felix Meschberger fmesc...@gmail.com Hi, Here are the Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0 releases. For the Web Console Branding we fixed 3 issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12314456 For the Web Console Security Provider one issue was fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315265 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-131/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 131 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix -- *Regards,* *Victor Taranenko*
Re: [VOTE] Release Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0
+1 Carsten Felix Meschberger wrote Hi, Here are the Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0 releases. For the Web Console Branding we fixed 3 issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12314456 For the Web Console Security Provider one issue was fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315265 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-131/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 131 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0
+1 to both. On 8/21/10 4:56 PM, Felix Meschberger wrote: Hi, Here are the Apache Sling Web Console Branding 1.0.0 and Apache Sling Web Console Security Provider 1.0.0 releases. For the Web Console Branding we fixed 3 issues: https://issues.apache.org/jira/browse/SLING/fixforversion/12314456 For the Web Console Security Provider one issue was fixed: https://issues.apache.org/jira/browse/SLING/fixforversion/12315265 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-131/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 131 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
WebDAV
Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
Hudson build is still unstable: sling-trun k-1.5 » Apache Sling Launchpad Testing #843
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/843/
Hudson build is still unstable: sling-trunk-1.5 #843
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/changes
Re: WebDAV
Looks very interesting, and might solve some of the problems we have been having caused by pooled content that has no structure. Presumably the webdav is writable and will present anything that is resolvable. Any idea how it copes with non listable parent resources? (listChildren returns an empty list) Ian On 23 Aug 2010, at 13:58, Felix Meschberger wrote: Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
[jira] Resolved: (SLING-1370) Provide Pseudo Authentication Handler to support both Form Based Login and OpenID Login
[ https://issues.apache.org/jira/browse/SLING-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1370. -- Resolution: Fixed This can be resolved for now. Provide Pseudo Authentication Handler to support both Form Based Login and OpenID Login --- Key: SLING-1370 URL: https://issues.apache.org/jira/browse/SLING-1370 Project: Sling Issue Type: New Feature Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Selector 1.0.0 Currently Sling has two form-oriented authentication handlers: The form based authentication handler and the OpenID authentication handler. But there is no good way for the real client of a Sling application to choose between the two authentication such as is provided for example by http://www.crowdvine.com/account/login. This can be accomplished by a pseudo authentication handler as follows: extractCredentials: not implemented, always returns null dropCredentials: not implemented requestCredentials: renders a configurable login form The handler is registered at higher priority than the authentication handlers actually handling the authentication (requires SLING-1368) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1361) The Authenticator.login method is specified to complete the response but it currently is not enforced
[ https://issues.apache.org/jira/browse/SLING-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1361: - Component/s: Authentication (was: Commons) The Authenticator.login method is specified to complete the response but it currently is not enforced - Key: SLING-1361 URL: https://issues.apache.org/jira/browse/SLING-1361 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 The Authenticator.login method is specified to complete the response to the client. This currently depends on the login handlers to actually send a response back. If none of the handlers actually commits the response, for example the HTTP Basic handler just does nothing and the Form Based Authentication Handler just clears the cookie, the login method implementation should probably handle finishing the response by redirecting back to either the refere (if any) or to the servlet context root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1155) Add logout method to Authenticator
[ https://issues.apache.org/jira/browse/SLING-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1155: - Component/s: Authentication (was: Engine) (was: Commons) Add logout method to Authenticator -- Key: SLING-1155 URL: https://issues.apache.org/jira/browse/SLING-1155 Project: Sling Issue Type: New Feature Components: Authentication Affects Versions: Engine 2.0.4, Engine 2.0.6 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 With the Sling Engine 2.0.4 the Authenticator interface has been introduced to support a generic way to have a user authenticated. This allows for an authentication agnostic way to force a user to login. The drawback of the current solution is, that neither authentication handlers nor the Authenticator interface provide APi to logout a user again. This should be fixed as follows: * Add an Authenticator.logout() method which logs out a user in a similar way the login method logs a user in * Add a new AuthenticationHandler2 interface extending the AuthenticationHandler interface and providing a dropAuthentication method which mirrors the AuthenticationHandler.requestAuthentication method. * Add a LogoutServlet calling Authenticator.logout in a similar manner as the LoginServlet calls the login method Authentication handlers supporting logging out just implement the AuthenticationHandler2 interface while still registering as a plain AuthenticationHandler. The Authenticator implementation in the Sling Engine bundle identifies the authentication handlers correctly to call or to not call the dropAuthentication method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1297) EngineSlingAuthenticator must wrap new exception
[ https://issues.apache.org/jira/browse/SLING-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1297: - Component/s: Authentication (was: Commons) EngineSlingAuthenticator must wrap new exception Key: SLING-1297 URL: https://issues.apache.org/jira/browse/SLING-1297 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 The EngineSlingAuthenticator class implements the old Engine's Authenticator service calling into the new service. The optional exception thrown by the Authenticator.login method must be translated by from org.apache.sling.commons.auth.NoAuthenticationHandlerException to org.apache.sling.engine.auth.NoAuthenticationHandlerException, otherwise applications using the old API may break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1292) Logout the primary session after successful impersonation
[ https://issues.apache.org/jira/browse/SLING-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1292: - Component/s: Authentication (was: Commons) Logout the primary session after successful impersonation - Key: SLING-1292 URL: https://issues.apache.org/jira/browse/SLING-1292 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 When using the impersonation feature of the Sling Authenticator (using the sudo request parameter) the primary session is never logged out and may cause OutOfMemory situations later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1265) Adapt OpenID Authentication Handler to new AuthenticationHandler API
[ https://issues.apache.org/jira/browse/SLING-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1265: - Component/s: Authentication (was: Extensions) Adapt OpenID Authentication Handler to new AuthenticationHandler API Key: SLING-1265 URL: https://issues.apache.org/jira/browse/SLING-1265 Project: Sling Issue Type: Sub-task Components: Authentication Affects Versions: Extensions OpenID Authentication 0.9.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: OpenID Authentication 1.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1497) FormAuth's service ranking should be configurable
[ https://issues.apache.org/jira/browse/SLING-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1497: - Component/s: Authentication (was: Extensions) FormAuth's service ranking should be configurable - Key: SLING-1497 URL: https://issues.apache.org/jira/browse/SLING-1497 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Form Based Authentication 1.0.0 Because Commons Auth uses service.ranking to order authentication handlers, this property needs to be configurable. There's a bug in the SCR Plugin which makes this difficult to surface in the web console, but once that's fixed, this be easy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1650) Move commons auth to another location
[ https://issues.apache.org/jira/browse/SLING-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1650: - Component/s: Authentication (was: Commons) Move commons auth to another location - Key: SLING-1650 URL: https://issues.apache.org/jira/browse/SLING-1650 Project: Sling Issue Type: Task Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Carsten Ziegeler Assignee: Felix Meschberger Fix For: OpenID Authentication 1.0.0, Form Based Authentication 1.0.0, Auth Core 1.0.0 As the commons auth uses the Sling API it is by definition no commons module :) To move the different authentication related parts together, the following structure is created: bundles/auth -- New Component, reflected in JIRA as the Authentication component commons/auth -- moved to bundles/auth/core and then the core authentication bundle extensions/formauth -- moved to bundles/auth/form extensions/openidauth -- moved to bundles/auth/openid -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: WebDAV
We intend to implement this feature into the jQuery Explorer, i.e. being able to switch between JCR-View and Sling/Resource-View. In the end WebDAV only makes sense for folders/files, whereas the explorer is more generic... -Original Message- From: Ian Boston [mailto:ianbos...@gmail.com]on Behalf Of Ian Boston Sent: Monday, August 23, 2010 3:12 PM To: dev@sling.apache.org Subject: Re: WebDAV Looks very interesting, and might solve some of the problems we have been having caused by pooled content that has no structure. Presumably the webdav is writable and will present anything that is resolvable. Any idea how it copes with non listable parent resources? (listChildren returns an empty list) Ian On 23 Aug 2010, at 13:58, Felix Meschberger wrote: Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
[jira] Updated: (SLING-1375) Allow authentication handlers to return information about failed authentication extraction
[ https://issues.apache.org/jira/browse/SLING-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1375: - Component/s: Authentication (was: Commons) Allow authentication handlers to return information about failed authentication extraction -- Key: SLING-1375 URL: https://issues.apache.org/jira/browse/SLING-1375 Project: Sling Issue Type: New Feature Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 AuthenticationHandler implementations currently can only return either DOING_AUTH or a concrete AuthenticationInfo object from the extractCredentials method. Sometimes the credentials provided in the request may not be valid and authentication handlers may want to force reauthentication instead of just letting the request pass through as an anonymous request. Examples of such failures are the form based authentication handler encountering an authentication cookie which has expired or the OpenID authentication handler encountering a failed OpenID authentication. In such failure cases the authentication handler should be able to provide this information to the sling authenticator and allow the authenticator to restart the authentication procedure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1554) Restore support for authentication-handler-specific Credentials
[ https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1554: - Component/s: Authentication (was: Commons) Restore support for authentication-handler-specific Credentials --- Key: SLING-1554 URL: https://issues.apache.org/jira/browse/SLING-1554 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Extensions OpenID Authentication 0.9.0 Reporter: Ray Davis Fix For: OpenID Authentication 1.0.0 Jackrabbit 1.6.2's standard repository login accepted any implementation of Credentials. This let Sling authentication plugins define their own Credentials classes, and the OpenID Authentication extension creates a component-specific Credentials class in its extractCredentials method and checks it in canHandle. Jackrabbit 2.0 changed the AbstractLoginModule to reject Credentials classes other than SimpleCredentials and GuestCredentials. As a result, by default getCredentials will return null if an AuthenticationHandler supplied any other implementation. A superclass of DefaultLoginModule has two ways around this: to override getCredentials() or to override supportCredentials(). Currently, Sling's PluggableDefaultLoginModule overrides getCredentials but does so only to allow for Sling's TrustedCredentials class. Either the PluggableDefaultLoginModule should let LoginModulePlugin implementations use their own Credentials classes (by doing the usual loop around canHandle(creds)), or the restriction should be documented and the OpenID extension changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1641) HTTP Authenticator does not behave correctly
[ https://issues.apache.org/jira/browse/SLING-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1641: - Component/s: Authentication (was: Commons) HTTP Authenticator does not behave correctly Key: SLING-1641 URL: https://issues.apache.org/jira/browse/SLING-1641 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 The HTTP Authenticator included with the Commons Auth bundle currently does not behave well with respect to logging out and requesting credentials: (1) sling:authRequestLogin parameter The sling:authRequestLogin parameter should be supported with both values BASIC (for new mechanism) and 1 for backwards compatibility. Setting the parameter should always cause a 401 response from the authentication handler (2) sendUnauthorized The method should not do anything (except logging) if called on a committed response (3) dropCredentials The dropCredentials method should always send a 401 response if the Authorization header is set in the response and the response has not been committed yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1564) allow the form authentication handler to include the login form as a servlet resource rather than doing a redirect
[ https://issues.apache.org/jira/browse/SLING-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1564: - Component/s: Authentication (was: Extensions) allow the form authentication handler to include the login form as a servlet resource rather than doing a redirect -- Key: SLING-1564 URL: https://issues.apache.org/jira/browse/SLING-1564 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Fix For: Form Based Authentication 1.0.0 this is intended to be an option, with the default being to redirect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1587) token file name isn't logged
[ https://issues.apache.org/jira/browse/SLING-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1587: - Component/s: Authentication (was: Extensions) token file name isn't logged Key: SLING-1587 URL: https://issues.apache.org/jira/browse/SLING-1587 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Priority: Trivial Fix For: Form Based Authentication 1.0.0 There's a log line in TokenStore which should print out the token file name, but doesn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1293) Impersonation failure not handled properly
[ https://issues.apache.org/jira/browse/SLING-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1293: - Component/s: Authentication (was: Commons) Impersonation failure not handled properly -- Key: SLING-1293 URL: https://issues.apache.org/jira/browse/SLING-1293 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 If impersonation fails, the sling authenticator acts the same as if the primary authentication would fail, that is calling the login() method selecting an authentication handle to request credentials with. This is unexpected behaviour and there is no indication, that impersonation failed but primary authentication succeeded. It would be better to either disable impersonation after the failure (or to fail the request with a proper status, e.g. 403/FORBIDDEN). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-966) Make internal sling authentication publicly available
[ https://issues.apache.org/jira/browse/SLING-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-966: Component/s: Authentication (was: Commons) Make internal sling authentication publicly available - Key: SLING-966 URL: https://issues.apache.org/jira/browse/SLING-966 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Attachments: SLING-966.patch, SLING-966b.patch, SLING-966c.patch Currently the SlingAuthenticator is an internal class in the Engine bundle, which is used by the SlingMainServlet to handle the authentication as part of an OSGi HTTP Service specification HttpContext object. To use the Sling authentication framework with the Authenticator and the AuthenticationHandlers outside of the SlingMainServlet, that is for other servlets directly registered with the OSGi HttpService the authentication functionality should be made publicly available. One approach would be to provide a new authenticate() method in the Authenticator interface. Another option would be to provide an abstract HttpContext which already implements the HttpContext.handleSecurity method using the SlingAuthenticator instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1508) Default auth handlers are not considered if a handler has a protocol or host
[ https://issues.apache.org/jira/browse/SLING-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1508: - Component/s: Authentication (was: Commons) Default auth handlers are not considered if a handler has a protocol or host Key: SLING-1508 URL: https://issues.apache.org/jira/browse/SLING-1508 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Auth Core 1.0.0 Attachments: SLING1508 The PathBasedHolderCache builds a map of maps for auth handlers. The first map is by protocol, the second map by host. If now a auth handler has a protocol and/or a host, the created list does not contain the default/fallback authhandlers (which don't have a protocol and host set). So as soon as one handler has a protocol/host, default handlers are not considered anymore -- 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 ] Felix Meschberger updated SLING-1444: - Component/s: Authentication (was: Commons) add an AuthenticationInfoPostProcessor service interface Key: SLING-1444 URL: https://issues.apache.org/jira/browse/SLING-1444 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Auth Core 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] Updated: (SLING-1493) Don't register authentication handler holder if service cannot be retrieved
[ https://issues.apache.org/jira/browse/SLING-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1493: - Component/s: Authentication (was: Commons) Don't register authentication handler holder if service cannot be retrieved --- Key: SLING-1493 URL: https://issues.apache.org/jira/browse/SLING-1493 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Under some conditions the SlingAuthenticator.AuthenticationHandlerTracker.addingService(ServiceReference reference) method cannot actually get the service from the framework. In this case the handler holder should not be created and registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1383) Provide out-of-the-box HTTP Basic authentication handler in the Commons Auth bundle
[ https://issues.apache.org/jira/browse/SLING-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1383: - Component/s: Authentication (was: Commons) Provide out-of-the-box HTTP Basic authentication handler in the Commons Auth bundle --- Key: SLING-1383 URL: https://issues.apache.org/jira/browse/SLING-1383 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: Auth Core 1.0.0 Attachments: SLING-1383.patch As discussed in http://markmail.org/thread/kyy25qmfus66son3 the existing HTTP Basic authentication handler should be merged into the Commons Auth bundle with the following simplifications: * Form support is dropped entirely * extractCredentials will always be enabled to support pre-emptive authentication (e.g. for HTTP Client applications) * requestCredentials disabled by default, may be enabled by configuration * dropCredentials disabled by defualt, may be configured to send 401 by configuration Note on Form support: I turns out, that form support is very complicated for the Internet Explorer and Firefox class browsers and impossible to support for WebKit class browsers like Chrome and Safari. So instead of further maintaining a complicated codebase with lots of special cases, it is better to support the basic case of simple HTTP Basic authentication out of the box and to do form based authentication right (as with the Form Based Authenticationhandler). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1306) Authentication Handler service registration property update not registered by Sling Authenticator
[ https://issues.apache.org/jira/browse/SLING-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1306: - Component/s: Authentication (was: Commons) Authentication Handler service registration property update not registered by Sling Authenticator - Key: SLING-1306 URL: https://issues.apache.org/jira/browse/SLING-1306 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Due to a current limitation of the (official) SCR specification, service registration property updates are not propagated to referring components. Thus if an authentication handler is updating its service registration properties to register new paths, this is not recored by the Sling Authenticator and authentication may consequently fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1116) FORM Based Authentication
[ https://issues.apache.org/jira/browse/SLING-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1116: - Component/s: Authentication (was: Extensions) FORM Based Authentication - Key: SLING-1116 URL: https://issues.apache.org/jira/browse/SLING-1116 Project: Sling Issue Type: New Feature Components: Authentication Reporter: Eric Norman Assignee: Felix Meschberger Fix For: Form Based Authentication 1.0.0 Attachments: org.apache.sling.cookieauth.zip, org.apache.sling.sessionauth.zip, SLING_1116_jackrabbit_server_patch.txt, update2_org.apache.sling.cookieauth.zip, updated_org.apache.sling.cookieauth.zip This is a new bundle that provides an implementation of forms based authentication for sling. The login/logout servlets from the org.apache.sling.commons.auth are used. The AuthenticationHandler will use http basic auth credentials if they are on the request, otherwise it will use the user/pwd posted from the login form. The login form html is generated by a set of scripts 1. login.html.esp - full login page (includes login_body.html.esp for the form markup) 2. login_body.html.esp - just the login form, which may be useful for drawing the login form for an ajax context 3. loginError.html.esp - full login-error page 4. loginError_body.html.esp - just the login-error form, for login error in ajax context The above scripts are included as bundle-resources @ /libs/sling/servlet/default The bundle also has a couple of test scripts to show some examples of usage: 1. loginTest.html.esp - shows who is logged in and links to login or logout 2. loginTest2.html.esp - shows how a script can check permissions and show a login page if the anonymous user doesn't have permission to see the page, Some examples of usage are: 1. http://host:port/path/to/node.login.html - show the login page and then goto http://host:port/path/to/node after authenticated 2. http://host:port/path/to/node.login.html?s=.edit.html - show the login page and then goto http://host:port/path/to/node.edit.html after authenticated 3. http://host:port/system/sling/logout - invalidate the session and switch back to anonymous user -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1614) Form Auth is not returning user to anonymous JCR state after timeout
[ https://issues.apache.org/jira/browse/SLING-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1614: - Component/s: Authentication (was: Extensions) Form Auth is not returning user to anonymous JCR state after timeout - Key: SLING-1614 URL: https://issues.apache.org/jira/browse/SLING-1614 Project: Sling Issue Type: Bug Components: Authentication Reporter: Mike Moulton Assignee: Ian Boston Fix For: Form Based Authentication 1.0.0 Per a discussion on the dev list [1], it looks like the Form Auth extension is not properly handling timeouts. Steps to reproduce: - Start up the standalone sling. - Install the form auth bundle. - Goto: http://localhost:8080/index.html - page should render - Goto: http://localhost:8080/system/sling/form/login - login - Goto: http://localhost:8080/index.html - page should still render - Wait for session cookie to timeout (I lowered the timeout to 1 min for my testing) - Refresh: http://localhost:8080/index.html - page will redirect to login form Expected behavior is that the form auth handler will return the session to an anonymous state if the cookie has timed out. Related to SLING-1588 [1] http://sling.markmail.org/thread/mqp3e7xkrtggpsef -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1588) form auth can create an endless redirect loop
[ https://issues.apache.org/jira/browse/SLING-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1588: - Component/s: Authentication (was: Extensions) form auth can create an endless redirect loop - Key: SLING-1588 URL: https://issues.apache.org/jira/browse/SLING-1588 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson Priority: Critical Fix For: Form Based Authentication 1.0.0 Steps to reproduce (I'm sure there's more than one way to reproduce this): * Take trunk launchpad and add formauth bundle * Set service.ranking of FormAuthenticationHandler to 0 Then... curl -v -b sling.formauth=garbage http://localhost:/index.html redirects to http://localhost:/system/sling/form/login?resource=%2Findex.htmlj_reason=TIMEOUT so try this url: curl -v -b sling.formauth=garbage http://localhost:/system/sling/form/login?resource=%2Findex.html\j_reason=TIMEOUT which redirects to: http://localhost:/system/sling/form/login?resource=%2Fsystem%2Fsling%2Fform%2Floginj_reason=TIMEOUT requesting that url with a garbage cookie redirects again and again and again... workaround is to enable the Include Form option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1374) Align OpenID authentiction handler with new Commons Auth
[ https://issues.apache.org/jira/browse/SLING-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1374: - Component/s: Authentication (was: Extensions) Align OpenID authentiction handler with new Commons Auth Key: SLING-1374 URL: https://issues.apache.org/jira/browse/SLING-1374 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Extensions OpenID Authentication 0.9.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: OpenID Authentication 1.0.0 The OpenID authentication handler contains much of today's Commons Auth support for login forms and feedback provisioning. This should be refactored to make the authentication handler simpler and align it with the Commons Auth functionality -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1298) Update Authentication Documentation with Impersonation support info
[ https://issues.apache.org/jira/browse/SLING-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1298: - Component/s: Authentication (was: Commons) Update Authentication Documentation with Impersonation support info --- Key: SLING-1298 URL: https://issues.apache.org/jira/browse/SLING-1298 Project: Sling Issue Type: Task Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Currently the Sling authentication documentation page at http://sling.apache.org/site/authentication.html does not provide any information on support for user impersonation by the Sling Authenticator. This should be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1314) Add support for login feedback from Authenticator to authentication handler
[ https://issues.apache.org/jira/browse/SLING-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1314: - Component/s: Authentication (was: Commons) Add support for login feedback from Authenticator to authentication handler --- Key: SLING-1314 URL: https://issues.apache.org/jira/browse/SLING-1314 Project: Sling Issue Type: New Feature Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Attachments: SLING-1314.patch, SLING-1314_fix_AuthenticationInfo_remove.txt There might be situations (or AuthenticationHandlers, actually), desiring to get feedback on the outcome of authentication after providing authentication credentials. At the moment this feedback is limited to the case of failed login when the SlingAuthenticator calls back into the AuthenticationHandler to request credentials. But this is only indirect feedback in the failure case. I propose to extend the feedback transfer as follows: * Add AuthenticationFeedbackHandler interface with two methods: // called if authentication failed, handler is not expected to send response // since SlingAuthenticator will call requestCredentials void authenticationFailed(HttpServletRequest, HttpServletResponse, AuthenticationInfo) // called if authentication succeeded, handler may write into the response // particularly setting a cookie or the like is possible here void authenticationSucceeded(HttpServletRequest, HttpServletResponse, AuthenticationInfo) * Add two methods to the AuthenticationInfo class to pass in a feedback handler: // May be called by the AuthenticationHandler to request feedback on the authentication void setAuthenticationFeedbackHandler(AuthenticationFeedbackHandler) // forward to configured feedback handler, ignored if none void authenticationFailed(HttpServletRequest, HttpServletResponse) // forward to configured feedback handler or handle redirect request if none void authenticationSucceeded(HttpServletRequest, HttpServletResponse) * SlingAuthenticator calls the new AuthenticationInfo methods on success or failure after login * The default behaviour of the AuthenticationInfo.authenticationSucceeded is to redirect to a desired target. This moves the SlingAuthenticator.handleRedirect method to a (probably) new static method, which is called by the AuthenticationInfo class and which may also be called by any implementation of the AuthenticationFeedbackHandler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1419) Remove dependency to JCR
[ https://issues.apache.org/jira/browse/SLING-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1419: - Component/s: Authentication (was: Commons) Remove dependency to JCR Key: SLING-1419 URL: https://issues.apache.org/jira/browse/SLING-1419 Project: Sling Issue Type: Improvement Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Carsten Ziegeler Fix For: Auth Core 1.0.0 The commons auth module as independent functionality wrt to JCR therefore we should make it work without JCR With SLING-1262 implemented, we can use the ResourceResolverFactory to login instead of going through the SlingRepository. In addition we should: - drop the setter and getter methods for credentials in the AuthenticationInfo - we keep the constant though - drop the setter and getter method for the workspace in the AuthenticationInfo - we keep the constant We make the import to the jcr packages optional as these are required for compatibility support of the old engine packages. If someone wants to use this support he'll need the jcr api anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1368) Support ordering of authentication handlers
[ https://issues.apache.org/jira/browse/SLING-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1368: - Component/s: Authentication (was: Commons) Support ordering of authentication handlers --- Key: SLING-1368 URL: https://issues.apache.org/jira/browse/SLING-1368 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Right now authentication handlers are only ordered by their registration path. If multiple authentication handlers are registered for the same path, the order at which they are asked is basically undefined. It would be useful to be able to control this order using the regular service.ranking service registration property. One use of such ordering would be to be able to better control which authentication handler should be in charge of requesting credentials. For example, a high priority pseudo authentication handler could be provided, which just renders login forms. Such a provider could provide forms for both form based authentication and OpenID authentication and support the client in selecting which form of authentication she/he selects. Such an authentication handler should of course have precedence in terms of requesting credentials over the other authentication handlers. Adding support for service.ranking would solve this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1294) Add functionality to redirect to a new request target after successful authentication
[ https://issues.apache.org/jira/browse/SLING-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1294: - Component/s: Authentication (was: Commons) Add functionality to redirect to a new request target after successful authentication - Key: SLING-1294 URL: https://issues.apache.org/jira/browse/SLING-1294 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 Some times, it would be desirable to get redirected to a new target after authentication was successful. The sling authenticator should be extended to support this functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1380) LoginModulePlugin should not implement getPrincipal method
[ https://issues.apache.org/jira/browse/SLING-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1380: - Component/s: Authentication (was: Extensions) LoginModulePlugin should not implement getPrincipal method -- Key: SLING-1380 URL: https://issues.apache.org/jira/browse/SLING-1380 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Form Based Authentication 1.0.0 The LoginModulePlugin.getPrincipal method overrides the DefaultLoginModule.getPrincipal method to return a prinicipal for the authenticated user. The drawback when overwriting this is, that the DefaultLoginModule's implementation actually gets a Principal which is based on the Jackrabbit UserManager from the user name encoded in the Credentials object as returned by the getUserID(Credentials) method. Since the Form Based Authentication uses a SimpleCredentials the DefaultLoginModule can cope with this and nothing more is needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1498) FormAuth doesn't store the original resource to redirect back to
[ https://issues.apache.org/jira/browse/SLING-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1498: - Component/s: Authentication (was: Extensions) FormAuth doesn't store the original resource to redirect back to - Key: SLING-1498 URL: https://issues.apache.org/jira/browse/SLING-1498 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Form Based Authentication 1.0.0 Attachments: SLING-1498.patch Unless I'm missing something significant, although FormAuth is capable of redirecting to a resource upon login, the logic which builds the redirect URL to the login page doesn't do this correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1382) Define means for an authentication handler to provide information on the implemented authentication type
[
https://issues.apache.org/jira/browse/SLING-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-1382:
-
Component/s: Authentication
(was: Commons)
Define means for an authentication handler to provide information on the
implemented authentication type
Key: SLING-1382
URL: https://issues.apache.org/jira/browse/SLING-1382
Project: Sling
Issue Type: New Feature
Components: Authentication
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: Auth Core 1.0.0
The AuthenticationHandler interface should be extended with the following two
constants:
/**
* The name of the service registration property (single string) providing
* the authentication type of authentication handler. This is the same
value
* as will be returned as the {...@link AuthenticationInfo#getAuthType()
* authentication type} returned by the
* {...@link #extractCredentials(HttpServletRequest, HttpServletResponse)}
* method.
* p
* p
* This property is optional but allows the client to optionally select
the
* authentication handler which will actually request credentials upon the
* {...@link #requestCredentials(HttpServletRequest, HttpServletResponse)}
* method.
*
* @see #REQUEST_LOGIN_PARAMETER
*/
static final String TYPE_PROPERTY = authtype;
/**
* The request parameter which may be used to explicitly select an
* authentication handler by its {...@link #TYPE_PROPERTY type} if
* authentication will be requested through
* {...@link #requestCredentials(HttpServletRequest,
HttpServletResponse)}.
*
* @see #requestCredentials(HttpServletRequest, HttpServletResponse)
* @see #TYPE_PROPERTY
*/
static final String REQUEST_LOGIN_PARAMETER = sling:authRequestLogin;
This allows for client-side selection of a concrete authentication handler to
use for requesting credentials and also to inquire about authentication types
of registered authentication handlers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1291) Set id of impersonating user as session attribute of impersonated session
[ https://issues.apache.org/jira/browse/SLING-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1291: - Component/s: Authentication (was: Commons) Set id of impersonating user as session attribute of impersonated session - Key: SLING-1291 URL: https://issues.apache.org/jira/browse/SLING-1291 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 When using the impersonation feature of the Sling Authenticator (using the sudo request parameter) it is currently not possible to find out whether the request session is a primarily authenticated session or an impersonated session. To be able to ask for this information, the id of the primary authenticated user could be set as an attribute of the impersonated session. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1534) switch SlingAuthenticator to use ResourceResolverFactory API rather than JCR directory
[ https://issues.apache.org/jira/browse/SLING-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1534: - Component/s: Authentication (was: Commons) switch SlingAuthenticator to use ResourceResolverFactory API rather than JCR directory -- Key: SLING-1534 URL: https://issues.apache.org/jira/browse/SLING-1534 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Auth Core 1.0.0 Attachments: SLING-1534.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1287) Impersonation cookie must be quoted to support some special characters
[
https://issues.apache.org/jira/browse/SLING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated SLING-1287:
-
Component/s: Authentication
(was: Commons)
Impersonation cookie must be quoted to support some special characters
--
Key: SLING-1287
URL: https://issues.apache.org/jira/browse/SLING-1287
Project: Sling
Issue Type: Bug
Components: Authentication
Affects Versions: Auth Core 1.0.0
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: Auth Core 1.0.0
The Sling authenticator supports transparent impersonation of another user
using a so called sudo parameter. Using this parameter causes the
authenticator to set a sudo cookie, which is inspected in future requests to
decide on whether to further impersonate requests or not.
The problem is, that the character set of cookie values is limited by RFC
2109 defining that a cookie value must be token or quoted-string according
to RFC-2616:
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
quoted-string = ( *(qdtext | quoted-pair ) )
qdtext = any TEXT except
If the sudo user name contains an @ sign (such as an email address), the
value is not a token any longer and must be properly quoted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1565) the formauth bundle should export the FormReason class
[ https://issues.apache.org/jira/browse/SLING-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1565: - Component/s: Authentication (was: Extensions) the formauth bundle should export the FormReason class -- Key: SLING-1565 URL: https://issues.apache.org/jira/browse/SLING-1565 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Justin Edelson Assignee: Felix Meschberger Fix For: Form Based Authentication 1.0.0 without exporting the FormReason class, other bundles cannot properly interpret the value of the j_reason parameter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1307) Internal Server Error if anonymous login is disabled but no authentication handler may be used
[ https://issues.apache.org/jira/browse/SLING-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1307: - Component/s: Authentication (was: Commons) Internal Server Error if anonymous login is disabled but no authentication handler may be used -- Key: SLING-1307 URL: https://issues.apache.org/jira/browse/SLING-1307 Project: Sling Issue Type: Bug Components: Authentication Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Auth Core 1.0.0 If anonymous access is disabled by configuration, but no authentication handler can be selected to authenticate the request, an Internal Server error is sent back to the client and a stack trace is logged : 20.01.2010 16:54:38 *MARK * servletengine: Servlet threw exception: org.apache.sling.commons.auth.NoAuthenticationHandlerException at org.apache.sling.commons.auth.impl.SlingAuthenticator.login(SlingAuthenticator.java:372) at org.apache.sling.commons.auth.impl.SlingAuthenticator.getAnonymousSession(SlingAuthenticator.java:560) at org.apache.sling.commons.auth.impl.SlingAuthenticator.handleSecurity(SlingAuthenticator.java:296) at org.apache.sling.engine.impl.SlingMainServlet.handleSecurity(SlingMainServlet.java:817) at org.apache.felix.http.base.internal.context.ServletContextImpl.handleSecurity(ServletContextImpl.java:224) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:86) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:77) The login method is defined to throw a NoAuthenticationHandlerException if no authentication handler can be found to handle the request. This exception must be caught by the getAnonymousSession method and converted into a sensible error such as 403/FORBIDDEN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1654) Remove JCR Session as request attribte
[ https://issues.apache.org/jira/browse/SLING-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1654: - Component/s: Authentication (was: Commons) Remove JCR Session as request attribte -- Key: SLING-1654 URL: https://issues.apache.org/jira/browse/SLING-1654 Project: Sling Issue Type: Task Components: Authentication, JCR Reporter: Felix Meschberger Assignee: Justin Edelson Fix For: JCR Webdav 2.0.10, Auth Core 1.0.0 Currently the SlingAuthenticator sets the following three request attributes in the Authenticator.handleSecurity method besides the attributes required by the OSGi Http Service spec: javax.jcr.Session -- the primary session underlying the resource resolver $$org.apache.sling.commons.auth.impl.SlingAuthenticatorResourceResolver$$ -- internal wrapper to help logout the resource resolver org.apache.sling.commons.auth.ResourceResolver -- the request's resource resolver The Session is here for backwards compatibility for a long time now. The official way to get at a session in requests has long been to adapt the request's resource resolver to a Session. Keeping the Session as a request attribute just makes cleaning up at the end more complicated. The $$org.apache.sling.commons.auth.impl.SlingAuthenticatorResourceResolver$$ request attribute has been introduce with the commons auth module but before the ResourceResolver.close() method to cleanup the resource resolver and session after request processing. This request attribute is not needed any longer thanks to the ResourceResolver.close() method which allows for propery cleanup. This the $$org.apache.sling.commons.auth.impl.SlingAuthenticatorResourceResolver$$ and javax.jcr.Session request attributes should not be set any longer. As kind of a replacement, JavaDoc of the Authenticator interface and particularly the Authenticator.handleSecurity method should be enhanced to list the request attributes be set and to request from the caller to call the close() method on the resource resovler at then end of request processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1647) Cleanup Authentication Info constants and implementation
[ https://issues.apache.org/jira/browse/SLING-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1647: - Component/s: Authentication (was: Commons) Cleanup Authentication Info constants and implementation Key: SLING-1647 URL: https://issues.apache.org/jira/browse/SLING-1647 Project: Sling Issue Type: Improvement Components: API, Authentication, JCR Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: JCR Resource 2.0.8, Auth Core 1.0.0, API 2.1.0 The constants defined on the AuthenticationInfo class in the Commons Auth bundle should be moved as follows: USER = user.name to the ResourceResolverFactory interface PASSWORD = user.password; to the ResourceResolverFactory interface CREDENTIALS = user.jcr.credentials; to the JcrResourceResolverFactory interface In addition support for checking the type of a credentials property is to be removed from the AuthenticationInfo class. Likewise the following constants currently internal to the JcrResourceResolverFactoryImpl class should be moved: AUTH_INFO_WORKSPACE = internal.user.jcr.workspace; to the JcrResourceResolverFactory interface and change value to user.jcr.workspace (removing the internal prefix) SESSION_ATTR_IMPERSONATOR = impersonator; to the ResourceResolverFactory interface Finally the following constant from the ResourceResolverFactory interface should be changed: SUDO_USER_ID = sudo.user.id; change the value to user.impersonation At the end use constants should be ensured, mostly in the JcrResourceResolverFactoryImpl and JcrResourceResolver classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: WebDAV
Hi, On 23.08.2010 15:17, Clemens Wyss wrote: We intend to implement this feature into the jQuery Explorer, i.e. being able to switch between JCR-View and Sling/Resource-View. In the end WebDAV only makes sense for folders/files, whereas the explorer is more generic... They are complements not concurrents ;-) Having a switch in the explorer is interesting, indeed. Regards Felix -Original Message- From: Ian Boston [mailto:ianbos...@gmail.com]on Behalf Of Ian Boston Sent: Monday, August 23, 2010 3:12 PM To: dev@sling.apache.org Subject: Re: WebDAV Looks very interesting, and might solve some of the problems we have been having caused by pooled content that has no structure. Presumably the webdav is writable and will present anything that is resolvable. Any idea how it copes with non listable parent resources? (listChildren returns an empty list) Ian On 23 Aug 2010, at 13:58, Felix Meschberger wrote: Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
Re: WebDAV
Hi, On 23.08.2010 15:11, Ian Boston wrote: Looks very interesting, and might solve some of the problems we have been having caused by pooled content that has no structure. Presumably the webdav is writable and will present anything that is resolvable. yes it is. Any idea how it copes with non listable parent resources? (listChildren returns an empty list) If the resource resolver provides them as SyntheticResources, they should be displayed as folders (I would assume). Regards Felix Ian On 23 Aug 2010, at 13:58, Felix Meschberger wrote: Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
RE: WebDAV
They are complements not concurrents ;-) +100 :-) -Original Message- From: Felix Meschberger [mailto:fmesc...@gmail.com] Sent: Monday, August 23, 2010 3:25 PM To: dev@sling.apache.org Subject: Re: WebDAV Hi, On 23.08.2010 15:17, Clemens Wyss wrote: We intend to implement this feature into the jQuery Explorer, i.e. being able to switch between JCR-View and Sling/Resource-View. In the end WebDAV only makes sense for folders/files, whereas the explorer is more generic... They are complements not concurrents ;-) Having a switch in the explorer is interesting, indeed. Regards Felix -Original Message- From: Ian Boston [mailto:ianbos...@gmail.com]on Behalf Of Ian Boston Sent: Monday, August 23, 2010 3:12 PM To: dev@sling.apache.org Subject: Re: WebDAV Looks very interesting, and might solve some of the problems we have been having caused by pooled content that has no structure. Presumably the webdav is writable and will present anything that is resolvable. Any idea how it copes with non listable parent resources? (listChildren returns an empty list) Ian On 23 Aug 2010, at 13:58, Felix Meschberger wrote: Hi all I stumbled upon a nice library to create WebDAV servers [1] and set out to create a simple WebDAV server to serve the Sling resource tree (everything available through the ResourceResovler) over WebDAV in a filesystem-like structure to enable file system mapping. In a sense it is comparable to the jcr/webdav bundle but exposing the whole resource tree instead of just the repository. In fact, resources registered using the Filesystem provider are even exposed as read/write. Currently this stuff is in my whitebox [2] for you to play around with. Wenn deployed the WebDAV server is at /milton (e.g. http//localhost:/milton). WDYT ? Would such a thing make sense in Sling 6 (or Sling 7) ? Regards Felix [1] http://milton.ettrema.com/index.html [2] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/milton
[jira] Created: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010 15:56:08.446 *ERROR* [FelixDispatchQueue] org.apache.sling.fsresource FrameworkEvent ERROR (org.osgi.framework.ServiceException: Service factory returned null.) org.osgi.framework.ServiceException: Service factory returned null. at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:340) at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:221) at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:295) at org.apache.felix.framework.Felix.getService(Felix.java:3007) at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:329) at
[jira] Commented: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
[ https://issues.apache.org/jira/browse/SLING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901411#action_12901411 ] Carsten Ziegeler commented on SLING-1680: - I haven't tested this yet on win xp - now the monitoring creates an entry status object for each file and directory in the configured tree. It traverses the whole directory tree - so if your c:/tmp dir is large, this may not be optimal. For the startup time we can definitly delay the scanning or do this in the background - but I don't have a good idea for the memory problem; except turning of the notification of file changes :( FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010
[jira] Commented: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
[ https://issues.apache.org/jira/browse/SLING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901417#action_12901417 ] Clemens Wyss commented on SLING-1680: - I can confirm that c:/ tmp is very deep and has many, many files( 100'000)/folders(40'000 ) ;-) I guess this bug/issue, being not a real world use case, can be ignored? FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010 15:56:08.446 *ERROR* [FelixDispatchQueue] org.apache.sling.fsresource FrameworkEvent ERROR (org.osgi.framework.ServiceException: Service factory returned null.) org.osgi.framework.ServiceException: Service factory returned null. at
[jira] Commented: (SLING-1680) FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError
[ https://issues.apache.org/jira/browse/SLING-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901420#action_12901420 ] Carsten Ziegeler commented on SLING-1680: - Hmm, yes, this is realy large :) Now, to be honest, I don't know if we should consider this a real world use case; I usually use the fs provider just for development, everything else (well nearly everything else) is in the repository later on. But I don't see a reason why we shoudln't support large file directories FsResourceProvider takes VERY long to register/unregister AND finally throws an OutOfMemoryError Key: SLING-1680 URL: https://issues.apache.org/jira/browse/SLING-1680 Project: Sling Issue Type: Bug Components: JCR Environment: WinXP, latest-greatest Sling (from trunk) Reporter: Clemens Wyss Given the Sling Web Console When I configure an instance of the filesystem resource provider in terms of provider root and filesystem location, e.g.: Provider root: /tmp Filesystem Root: c:/tmp it takes very long to handle the request an finally ends in an OutOfMemoryError: 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] The activate method has thrown an exception (java.lang.OutOfMemoryError: Java heap space) java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572) at java.lang.StringBuilder.append(StringBuilder.java:203) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:253) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) at org.apache.sling.fsprovider.internal.FileMonitor.createStatus(FileMonitor.java:219) at org.apache.sling.fsprovider.internal.FileMonitor.access$000(FileMonitor.java:36) at org.apache.sling.fsprovider.internal.FileMonitor$DirStatus.init(FileMonitor.java:255) 23.08.2010 15:56:08.446 *ERROR* [FelixStartLevel] org.apache.sling.fsresource [org.apache.sling.fsprovider.internal.FsResourceProvider] Failed creating the component instance; see log for reason 23.08.2010 15:56:08.446 *ERROR* [FelixDispatchQueue] org.apache.sling.fsresource FrameworkEvent ERROR
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
Case 1 should be working in trunk now. What's the Sling-Bundle-Resources header look like? In terms of case 2, if this was to be implemented, I don't think it should be up to the ResourceProvider implementation to create the SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. Even though this is easy to workaround, if we're serious about supporting WebDAV over the resource tree, supporting this is probably necessary. Justin On 8/23/10 4:17 AM, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
[jira] Created: (SLING-1682) add osgi and jcr install into launchpad
add osgi and jcr install into launchpad --- Key: SLING-1682 URL: https://issues.apache.org/jira/browse/SLING-1682 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Justin Edelson Fix For: Launchpad Builder 6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1681) Merge Installer into Reactor
Merge Installer into Reactor Key: SLING-1681 URL: https://issues.apache.org/jira/browse/SLING-1681 Project: Sling Issue Type: Improvement Components: General Reporter: Justin Edelson installer builds and test successfully, so we should merge it into the main reactor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: sling-trunk-1.6 #536
See https://hudson.apache.org/hudson/job/sling-trunk-1.6/536/changes Changes: [cziegeler] Use static loggers for data objects [cziegeler] Use static loggers for data objects [justin] removing unused imports [fmeschbe] Update to Sling API 2.1.0 [justin] SLING-1560 - removing path checking on observation events within the watched trees as this fails to account for cases where a non-matching path was moved [justin] using logback in testing [justin] update test for JR 2.1 issues [justin] adding quiet deletion method [fmeschbe] Set JIRA version id and fix JavaDoc exclusions [fmeschbe] Set JIRA version id and fix JavaDoc exclusions [fmeschbe] SLING-1678 Metatype Service labels [fmeschbe] SLING-1678 Add support to disable built-in HTTP Basic Authentication Handler SLING-1679 Use Apache Felix SCR Annotations (instead of @scr JavaDoc tags) [fmeschbe] SLING-1679 Use Apache Felix SCR Annotations (instead of @scr JavaDoc tags) [enorman] SLING-897 Updating a property fires the wrong JCR events [enorman] randomize ids for test users and groups to reduce the risk of collisions [enorman] SLING-897 Updating a property fires the wrong JCR events [fmeschbe] Code format [fmeschbe] Use API release 2.1.0 [fmeschbe] Upgrade to 1.0.1-SNAPSHOT during 1.0.0 release vote [fmeschbe] [maven-release-plugin] prepare for next development iteration [fmeschbe] [maven-release-plugin] prepare release org.apache.sling.extensions.webconsolesecurityprovider-1.0.0 [fmeschbe] [maven-release-plugin] prepare for next development iteration [fmeschbe] [maven-release-plugin] prepare release org.apache.sling.extensions.webconsolebranding-1.0.0 [fmeschbe] Prevent JavaDoc reporting to run (nothing to JavaDoc here) and refer to the JIRA version ID for the changes plugin [fmeschbe] SLING-1670 Add new webconsole security provider to build reactor and launchpad bundle list [fmeschbe] Fix license header [justin] SLING-1660 - upgrading to JR 2.1.1 [justin] SLING-1674 - adding mapped path handling of parent path [fmeschbe] SLING-1611 Add attributes of Platform MBeanServer delegate to the service registration of the Platform MBeanServer service as service properties [cziegeler] SLING-1673 : Cache results in SlingAdaptable [cziegeler] SLING-1673 : Cache results in SlingAdaptable [cziegeler] Make sure we include latest adapters, as we have some fixes here as well. [fmeschbe] SLING-1370 Add Selector pseudo authentication handler to build reactor and bundle list [fmeschbe] SLING-1634 Further improvements for login support: on the left hand side the login status is now listed with the user name and an option to log out (if logged in). If not logged in options are displayed to login or to signup. Added a simple, non-functional signup page. [fmeschbe] Format file for easier maintenance [fmeschbe] SLING-1370 First implementation of an authentication selector pseudo authentication handler [fmeschbe] SLING-1650 JavaDoc [fmeschbe] SLING-1670 add repository based security provider for the Web Console [fmeschbe] SLING-952 Applied the patch (thanks Federico Paparoni for providing it) [fmeschbe] SLING-1669 Only set the resource target request attribute to the request URL if neither the parameter is present nor the attribute is already set. [fmeschbe] SLING-1668 dynamically import the JCR API -- [...truncated 50 lines...] A bundles/auth/selector/src/main/java/org/apache/sling/auth A bundles/auth/selector/src/main/java/org/apache/sling/auth/selector AU bundles/auth/selector/src/main/java/org/apache/sling/auth/selector/SelectorFormServlet.java AU bundles/auth/selector/src/main/java/org/apache/sling/auth/selector/SelectorAuthenticationHandler.java A bundles/auth/selector/src/main/resources A bundles/auth/selector/src/main/resources/org A bundles/auth/selector/src/main/resources/org/apache A bundles/auth/selector/src/main/resources/org/apache/sling A bundles/auth/selector/src/main/resources/org/apache/sling/auth A bundles/auth/selector/src/main/resources/org/apache/sling/auth/selector AU bundles/auth/selector/src/main/resources/org/apache/sling/auth/selector/login.html AUbundles/auth/selector/pom.xml U bundles/auth/form/pom.xml U bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/HttpBasicAuthenticationHandler.java U bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/engine/EngineSlingAuthenticator.java U bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/SlingAuthenticator.java U bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/LoginServlet.java U bundles/auth/core/src/main/java/org/apache/sling/auth/core/impl/LogoutServlet.java U bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties U bundles/auth/core/pom.xml U
[jira] Resolved: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved SLING-1560. - Resolution: Fixed The InstallableResource is now a simple data object - all the logic like format detection etc is done inside the implementation This should give us room to make the installer pluggable without changing the api later on Done in revision 988214 I'm closing this bug for now as we've done a lot of changes Improve and clean up code - Key: SLING-1560 URL: https://issues.apache.org/jira/browse/SLING-1560 Project: Sling Issue Type: Improvement Components: Installer Affects Versions: OSGi Installer 3.0.0, JCR Installer 3.0.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: OSGi Installer 3.0.0, JCR Installer 3.0.0 In order to fix some outstanding bugs and to add new features, a code review and clean up seems to be a good idea :) This bug will keep track of all changes to the code that don't add new features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1683) MockResourceResolver does not implement new methods getAttribute, getAttributeNames and clone
[ https://issues.apache.org/jira/browse/SLING-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Müller resolved SLING-1683. Resolution: Fixed resolved in r988224 MockResourceResolver does not implement new methods getAttribute, getAttributeNames and clone - Key: SLING-1683 URL: https://issues.apache.org/jira/browse/SLING-1683 Project: Sling Issue Type: Test Components: Testing Reporter: Mike Müller Assignee: Mike Müller Priority: Minor This methods are added in SLING-1640 and SLING-1646 to the ResourceResolver interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1684) ScriptableResourceTest.TestResource does not implement new methods from Resource interface
[ https://issues.apache.org/jira/browse/SLING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Müller resolved SLING-1684. Resolution: Fixed resolved in r988227 ScriptableResourceTest.TestResource does not implement new methods from Resource interface -- Key: SLING-1684 URL: https://issues.apache.org/jira/browse/SLING-1684 Project: Sling Issue Type: Test Components: Testing Reporter: Mike Müller Assignee: Mike Müller Priority: Minor Following methods are added to Resource in SLING-1193: getName getChild getParent isResourceType listChildren -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
I can confirm that case 1) does work. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. agree, but in case of listChildren on any path/node/resource we could consult all resource providers (which correspond to/include this path) and concat all children. Hence we might even end up with same-named-siblings coming from different resource providers -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Monday, August 23, 2010 6:20 PM To: dev@sling.apache.org Subject: Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672) Case 1 should be working in trunk now. What's the Sling-Bundle-Resources header look like? In terms of case 2, if this was to be implemented, I don't think it should be up to the ResourceProvider implementation to create the SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. Even though this is easy to workaround, if we're serious about supporting WebDAV over the resource tree, supporting this is probably necessary. Justin On 8/23/10 4:17 AM, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
I can confirm that case 1) does work. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. agree, but in case of listChildren on any path/node/resource we could consult all resource providers (which correspond to/include this path) and concat all children. Hence we might even end up with same-named-siblings coming from different resource providers Case 1 should be working in trunk now. What's the Sling-Bundle-Resources header look like? In terms of case 2, if this was to be implemented, I don't think it should be up to the ResourceProvider implementation to create the SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. Even though this is easy to workaround, if we're serious about supporting WebDAV over the resource tree, supporting this is probably necessary. Justin I definitively think we should support this behavour. And I totaly agree that this should not be up to the ResourceProvider implementation to create the SyntheticResource objects for the parts of the path above. So in case 2) the ResourceResolver implementation should create SyntheticResource objects for /some and /some/path if the root path (provider.roots) is set to /some/path. Beneath /some/path the ResourceProvider implementation must make sure that traversing the resource tree down to a deeply nested provided resource is possible. best regards mike On 8/23/10 4:17 AM, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
Re: fixed the last (for me at least) failing installer test
Justin Edelson wrote I fixed the two failing test in JCR Installer. As mentioned last week, one failure (FolderDetectionTest.testMoveLibsToFoo) was caused by a Jackrabbit bug, for which I implemented a workaround. Great, thanks Justin! The second failure (FolderDetectionTest.testMoveLibsToApps) was caused by the fact that when session.move(/src, /dest) is called, events are sent only for NodeAdded /src and NodeRemoved /dest. The code in RootFolderListener expected to get a NodeAdded event for each node in the moved subtree. Looking at the JCR spec, Jackrabbit seems to be doing the right thing here, so I ended up removing the path checking code in r988136. The net result is that the watched subtrees (i.e. /apps and /libs) are scanned whenever any change is done inside of them. I'm certainly open to other alternatives for this. Sounds good to me. I've one question :) Do we need the dependency to JCR 2 for observation of the move event? As far as I can see this is currently the only place where jcr 2 api is used; otherwise the jcrinstaller would still work with jcr 1. I'm not against requiring JCR 2 for the installer but if it is just for this event, we might reduce the requirement to jcr 1 In any case, all the tests are passing for me now. Created SLING-1681 to merge it into the reactor and SLING-1682 to add jcr and osgi install to launchpad. Great I've committed my last changes, so the stuff should be ready for a release (there are still bugs I would like to get fixed, but as those are there for a long time, we can release SLING-6 with them). And I finally fixed a bug in the IT tests (the ConfigInstallTest#testDeferredConfigInstall) - at least in my environment there are two config admin bundles installed; as only one is stopped, the config admin is still there, making the test fail. I changed this to simply stop all config admins :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
OSGi Installer API
Hi, the current OSGi installer has three methods: - registerResources : which is used to register all resources from the installer client like jcr install; this is usually invoked on startup - addResource : adds a resource during runtime - removeResource : removes a resource during runtime The api is simple, fine and sufficient. However there is a small glitch here. If a client detects several changes at once, like a set of bundles is removed or updated, it has to call addResource or removeResource for each change separately. The OSGi installer could run a install cycle inbetween those method calls. Causing a part of this process to be done in the first cycle and the other part in the second cycle - now as OSGi has a dynamic nature this isn't a problem after two cycles everything is installed as expected. But still I have the feeling that it would be nicer, if the client could submit several changes add once, so maybe instead of having a addResource and removeResource method, just a updateResources([] addedResources, [] removedResources). WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: fixed the last (for me at least) failing installer test
On 8/23/10 2:20 PM, Carsten Ziegeler wrote: Justin Edelson wrote I fixed the two failing test in JCR Installer. As mentioned last week, one failure (FolderDetectionTest.testMoveLibsToFoo) was caused by a Jackrabbit bug, for which I implemented a workaround. Great, thanks Justin! np. The second failure (FolderDetectionTest.testMoveLibsToApps) was caused by the fact that when session.move(/src, /dest) is called, events are sent only for NodeAdded /src and NodeRemoved /dest. The code in RootFolderListener expected to get a NodeAdded event for each node in the moved subtree. Looking at the JCR spec, Jackrabbit seems to be doing the right thing here, so I ended up removing the path checking code in r988136. The net result is that the watched subtrees (i.e. /apps and /libs) are scanned whenever any change is done inside of them. I'm certainly open to other alternatives for this. Sounds good to me. I've one question :) Do we need the dependency to JCR 2 for observation of the move event? As far as I can see this is currently the only place where jcr 2 api is used; otherwise the jcrinstaller would still work with jcr 1. I'm not against requiring JCR 2 for the installer but if it is just for this event, we might reduce the requirement to jcr 1 The NODE_MOVED event shouldn't be there. I'll remove it. I inserted it as an attempt to fix the problem, but it didn't work and I forgot to take it out. We shouldn't need JCR 2. To be clear, this test (FolderDetectionTest.testMoveLibsToApps) would fail as it is currently written under JR 1 as well as JR 2. The only reason it passed before was because the move resulted in a NodeAdded event being fired for /apps, which caused /apps to be rescanned. The bug was that moving a subtree to /apps/foo didn't cause /apps to be rescanned. NodeAdded /apps - /apps get rescanned NodeAdded /apps/foo/install - /apps/foo/install gets rescanned NodeAdded /apps/foo - nothing happens So, in other words, making the test work with Jackrabbit 2 exposed a bug which had been there all along. In any case, all the tests are passing for me now. Created SLING-1681 to merge it into the reactor and SLING-1682 to add jcr and osgi install to launchpad. Great I've committed my last changes, so the stuff should be ready for a release (there are still bugs I would like to get fixed, but as those are there for a long time, we can release SLING-6 with them). And I finally fixed a bug in the IT tests (the ConfigInstallTest#testDeferredConfigInstall) - at least in my environment there are two config admin bundles installed; as only one is stopped, the config admin is still there, making the test fail. I changed this to simply stop all config admins :) That's odd; never saw that one. Justin Regards Carsten
can someone tell Adobe we're already using Launchpad :)
http://gregsramblings.com/2010/08/23/air-launchpad/
RE: can someone tell Adobe we're already using Launchpad :)
maybe that's the first benefit from the Adobe/Day merger ;-)) http://gregsramblings.com/2010/08/23/air-launchpad/
RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
I can confirm that case 1) does work. ...at least for FsResourceProvider resources, but not for BundleResourceProvider resources :-( Mixing jcr resources with bundle resources still doesn't work as expected. Having: Sling-Bundle-Resources /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer /Sling-Bundle-Resources and then creating the res/sling/explorer jcr structure (through WebDAV for example) only enlists the jcr tree but not the mixed in bundle resources -Original Message- From: Clemens Wyss [mailto:clemens...@mysign.ch] Sent: Monday, August 23, 2010 7:56 PM To: 'dev@sling.apache.org'; 'jus...@justinedelson.com' Subject: RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672) I can confirm that case 1) does work. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. agree, but in case of listChildren on any path/node/resource we could consult all resource providers (which correspond to/include this path) and concat all children. Hence we might even end up with same-named-siblings coming from different resource providers -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Monday, August 23, 2010 6:20 PM To: dev@sling.apache.org Subject: Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672) Case 1 should be working in trunk now. What's the Sling-Bundle-Resources header look like? In terms of case 2, if this was to be implemented, I don't think it should be up to the ResourceProvider implementation to create the SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. Even though this is easy to workaround, if we're serious about supporting WebDAV over the resource tree, supporting this is probably necessary. Justin On 8/23/10 4:17 AM, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
+1 Regards Felix On 23.08.2010 20:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
Re: fixed the last (for me at least) failing installer test
Justin Edelson wrote The NODE_MOVED event shouldn't be there. I'll remove it. I inserted it as an attempt to fix the problem, but it didn't work and I forgot to take it out. We shouldn't need JCR 2. To be clear, this test (FolderDetectionTest.testMoveLibsToApps) would fail as it is currently written under JR 1 as well as JR 2. The only reason it passed before was because the move resulted in a NodeAdded event being fired for /apps, which caused /apps to be rescanned. The bug was that moving a subtree to /apps/foo didn't cause /apps to be rescanned. NodeAdded /apps - /apps get rescanned NodeAdded /apps/foo/install - /apps/foo/install gets rescanned NodeAdded /apps/foo - nothing happens So, in other words, making the test work with Jackrabbit 2 exposed a bug which had been there all along. :) Perfect - so I think we're ready to release. I'll give the latest stuff a few test cycles in the next days, but I don't expect any new problems. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672)
On 8/23/10 2:48 PM, Clemens Wyss wrote: I can confirm that case 1) does work. ...at least for FsResourceProvider resources, but not for BundleResourceProvider resources :-( Mixing jcr resources with bundle resources still doesn't work as expected. Having: Sling-Bundle-Resources /res/sling/explorer;overwrite:=true;uninstall=true;path:=/libs/sling/explorer /Sling-Bundle-Resources and then creating the res/sling/explorer jcr structure (through WebDAV for example) only enlists the jcr tree but not the mixed in bundle resources This is SLING-1675. What's working in trunk is if Sling-Bundle-Resources was /res/sling. Already mentioned, but to be clear, overwrite and uninstall don't apply to bundle resources. Justin -Original Message- From: Clemens Wyss [mailto:clemens...@mysign.ch] Sent: Monday, August 23, 2010 7:56 PM To: 'dev@sling.apache.org'; 'jus...@justinedelson.com' Subject: RE: [DISCUSS] Correct listing of resource children (follow up to SLING-1672) I can confirm that case 1) does work. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. agree, but in case of listChildren on any path/node/resource we could consult all resource providers (which correspond to/include this path) and concat all children. Hence we might even end up with same-named-siblings coming from different resource providers -Original Message- From: Justin Edelson [mailto:justinedel...@gmail.com] Sent: Monday, August 23, 2010 6:20 PM To: dev@sling.apache.org Subject: Re: [DISCUSS] Correct listing of resource children (follow up to SLING-1672) Case 1 should be working in trunk now. What's the Sling-Bundle-Resources header look like? In terms of case 2, if this was to be implemented, I don't think it should be up to the ResourceProvider implementation to create the SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it shouldn't be expected to return resources for anything not starting with /foo/bar. Even though this is easy to workaround, if we're serious about supporting WebDAV over the resource tree, supporting this is probably necessary. Justin On 8/23/10 4:17 AM, Mike Müller wrote: Hi When getting a resource the case seems to be clear: The first resource provider which returns a resource *wins*. And the resource providers are called in order starting with the provider which is registered for the longest part of the requested path. With ResourceResolver#listChildren it's a bit trickier. Assume the following: structure in the JCR: /foo /foo/bar /foo/bar/test and in another resource provider: /foo/bar /foo/bar/myresource case 1) ResourceResolver#listChildren( /foo/bar ) should now list the following test myresource case 2) Assume another provider: /some/path/resource /some/path/resource2 What should ResourceResolver#listChildren( / ) list? From my understanding it should list: foo some where may be a SyntheticResource. case 1) and case 2) are not returning the expected result, at least not if you use a bundle resource provider. I haven't looked into the details so I can't say if it's a problem of the bundle resource provider or a more general problem with the resource resolver implementation. Maybe security could be a problem. But a resource provider at least can access the user id via ResourceResolver#getUserID, and list children only if access is allowed. I don't know if this behavour of a resource provider is intended. WDYT? best regards mike
[jira] Created: (SLING-1685) Method to force remove a job
Method to force remove a job Key: SLING-1685 URL: https://issues.apache.org/jira/browse/SLING-1685 Project: Sling Issue Type: New Feature Components: Extensions Affects Versions: Extensions Event 2.3.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Extensions Event 2.4.0 Currently it is only possible to try to remove an event - this might fail if the job is in processing; while this is fine, this usually creates a problem for the client as it really wants to stop the job. It is easy to implement the retry in the job handling than in the client code. Therefore we should add a forceRemoveJob method which waits until the job is removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1652) Upgrade Felix Framework to latest release
[ https://issues.apache.org/jira/browse/SLING-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1652. -- Resolution: Fixed Upgraded to the releases Felix Framework 3.0.2 in Rev. 988249 Upgrade Felix Framework to latest release - Key: SLING-1652 URL: https://issues.apache.org/jira/browse/SLING-1652 Project: Sling Issue Type: Task Components: Launchpad Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: Launchpad Base 2.2.2 Richard Hall hall published a 3.1.0-SNAPSHOT release to give the framework exposure before the 3.0.2 release to come in the short time frame. The Base module should be upgraded to this snapshot to test the snapshot and as soon as 3.0.2 is released, upgrade to that release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is still unstable: sling-trun k-1.5 » Apache Sling Launchpad Testing #844
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/org.apache.sling$org.apache.sling.launchpad.testing/844/
Hudson build is still unstable: sling-trunk-1.5 #844
See https://hudson.apache.org/hudson/job/sling-trunk-1.5/changes
Hudson build became unstable: sling-installer-1.5 » Apache Sling OSGi Installer Integration Tests #98
See https://hudson.apache.org/hudson/job/sling-installer-1.5/org.apache.sling$org.apache.sling.osgi.installer.it/98/changes
Hudson build is back to stable : sling-ins taller-1.5 » Apache Sling JCR Installer #98
See https://hudson.apache.org/hudson/job/sling-installer-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/98/changes
Build failed in Hudson: sling-contrib-1.5 #567
See https://hudson.apache.org/hudson/job/sling-contrib-1.5/567/changes
Changes:
[cziegeler] Use latest Sling API release
--
[...truncated 349 lines...]
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
[INFO] Writing OBR metadata
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/commons/html/target/org.apache.sling.commons.html-1.0.1-SNAPSHOT-sources.jar
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.commons.html/builds/2010-08-23_20-35-57/archive/org.apache.sling/org.apache.sling.commons.html/1.0.1-SNAPSHOT/org.apache.sling.commons.html-1.0.1-SNAPSHOT-sources.jar
[INFO]
[INFO] Building Apache Sling APT parser
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target
(included: [**], excluded: [])
[INFO] [enforcer:enforce {execution: enforce-java}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 3 resources
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, you'll get OutOfMemoryErrors when building
unless you set
[echo] MAVEN_OPTS=-Xmx256M -XX:MaxPermSize=128M, see SLING-443.
[echo]
*
[INFO] Executed tasks
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 7 source files to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/classes
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO] Writing abstract service descriptor
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/scr-plugin-generated/OSGI-INF/scr-plugin/scrinfo.xml
with 1 entries.
[INFO] Generating 1 Service Component Descriptors to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/scr-plugin-generated/OSGI-INF/serviceComponents.xml
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/test-classes
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/target/surefire-reports
---
T E S T S
---
Running org.apache.sling.apt.parser.internal.SlingAptParserImplTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec
Results :
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[HUDSON] Recording test results
[INFO] [bundle:bundle {execution: default-bundle}]
[WARNING] Warning building bundle
org.apache.sling:org.apache.sling.extensions.apt.parser:bundle:2.0.3-SNAPSHOT :
Split package org/apache/maven/doxia/sink
Use directive -split-package:=(merge-first|merge-last|error|first) on
Export/Private Package instruction to get rid of this warning
Package found in [Jar:doxia-core, Jar:doxia-sink-api]
Reference from
/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-10/doxia-sink-api-1.0-alpha-10.jar
Classpath [Jar:., Jar:doxia-module-apt, Jar:plexus-utils,
Jar:doxia-core, Jar:doxia-sink-api, Jar:plexus-container-default,
Jar:plexus-classworlds]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[HUDSON] Archiving
https://hudson.apache.org/hudson/job/sling-contrib-1.5/ws/contrib-1.5/extensions/apt/parser/pom.xml
to
/home/hudson/hudson/jobs/sling-contrib-1.5/modules/org.apache.sling$org.apache.sling.extensions.apt.parser/builds/2010-08-23_20-35-57/archive/org.apache.sling/org.apache.sling.extensions.apt.parser/2.0.3-SNAPSHOT/pom.xml
[jira] Created: (SLING-1686) AuthenticationInfoPostProcessors aren't invoked for basic auth
AuthenticationInfoPostProcessors aren't invoked for basic auth -- Key: SLING-1686 URL: https://issues.apache.org/jira/browse/SLING-1686 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson If the built-in http basic authentication handler is used, the AuthenticationInfoPostProcessor list won't be invoked for the extracted credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
-1 I just found a bug in Auth Core (SLING-1686). Felix - how do you feel about restaging the release? On 8/23/10 2:49 PM, Felix Meschberger wrote: +1 Regards Felix On 23.08.2010 20:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[jira] Commented: (SLING-1686) AuthenticationInfoPostProcessors aren't invoked for basic auth
[ https://issues.apache.org/jira/browse/SLING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901591#action_12901591 ] Justin Edelson commented on SLING-1686: --- fixed in r988314. be great to see this in the Auth Core 1.0.0 release (see my vote), but I'm leaving the Fix Version blank for now. AuthenticationInfoPostProcessors aren't invoked for basic auth -- Key: SLING-1686 URL: https://issues.apache.org/jira/browse/SLING-1686 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson If the built-in http basic authentication handler is used, the AuthenticationInfoPostProcessor list won't be invoked for the extracted credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1686) AuthenticationInfoPostProcessors aren't invoked for basic auth
[ https://issues.apache.org/jira/browse/SLING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson resolved SLING-1686. --- Resolution: Fixed AuthenticationInfoPostProcessors aren't invoked for basic auth -- Key: SLING-1686 URL: https://issues.apache.org/jira/browse/SLING-1686 Project: Sling Issue Type: Bug Components: Authentication Reporter: Justin Edelson If the built-in http basic authentication handler is used, the AuthenticationInfoPostProcessor list won't be invoked for the extracted credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
Hi, On 23.08.2010 23:14, Justin Edelson wrote: -1 I just found a bug in Auth Core (SLING-1686). I feared something like this could happen ... :-( Felix - how do you feel about restaging the release? Hmm, not too good because this would mean to restage all four of them. How about this: We continue voting on this one and I will prepare a 1.0.2 release of the core module first thing tomorrow. Regards Felix On 8/23/10 2:49 PM, Felix Meschberger wrote: +1 Regards Felix On 23.08.2010 20:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
On 8/23/10 5:27 PM, Felix Meschberger wrote: Hi, On 23.08.2010 23:14, Justin Edelson wrote: -1 I just found a bug in Auth Core (SLING-1686). I feared something like this could happen ... :-( My bad for not checking this when I initially implemented AuthInfoPostProcessors. Felix - how do you feel about restaging the release? Hmm, not too good because this would mean to restage all four of them. How about this: We continue voting on this one and I will prepare a 1.0.2 release of the core module first thing tomorrow. OK. Then I change my vote to +1. Justin Regards Felix On 8/23/10 2:49 PM, Felix Meschberger wrote: +1 Regards Felix On 23.08.2010 20:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
Re: [VOTE] Release Apache Sling Auth Core 1.0.0, Auth Form 1.0.0, Auth OpenID 1.0.0, Auth Selector 1.0.0
On 23.08.2010 23:31, Justin Edelson wrote: On 8/23/10 5:27 PM, Felix Meschberger wrote: Hi, On 23.08.2010 23:14, Justin Edelson wrote: -1 I just found a bug in Auth Core (SLING-1686). I feared something like this could happen ... :-( My bad for not checking this when I initially implemented AuthInfoPostProcessors. No problem. I didn't check either... Felix - how do you feel about restaging the release? Hmm, not too good because this would mean to restage all four of them. How about this: We continue voting on this one and I will prepare a 1.0.2 release of the core module first thing tomorrow. OK. Then I change my vote to +1. Thanks. Justin Regards Felix On 8/23/10 2:49 PM, Felix Meschberger wrote: +1 Regards Felix On 23.08.2010 20:48, Felix Meschberger wrote: Hi, Here are the 1.0.0 releases of the Apache Sling Auth Core, Auth Form, Auth OpenID, and Auth Selector bundles. We have solved 36 issues for Auth Core: https://issues.apache.org/jira/browse/SLING/fixforversion/12314514 We have solved 10 issues for Auth Form: https://issues.apache.org/jira/browse/SLING/fixforversion/12314785 We have solved 5 issues for Auth OpenID: https://issues.apache.org/jira/browse/SLING/fixforversion/12314515 We have solved one issue for the Auth Selector: https://issues.apache.org/jira/browse/SLING/fixforversion/12315263 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-135/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 135 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Felix
[jira] Commented: (SLING-1686) AuthenticationInfoPostProcessors aren't invoked for basic auth
[ https://issues.apache.org/jira/browse/SLING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901601#action_12901601 ] Felix Meschberger commented on SLING-1686: -- As discussed, the 1.0.0 release vote continues and I will cut a new RC for Auth Core. AuthenticationInfoPostProcessors aren't invoked for basic auth -- Key: SLING-1686 URL: https://issues.apache.org/jira/browse/SLING-1686 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Auth Core 1.0.2 If the built-in http basic authentication handler is used, the AuthenticationInfoPostProcessor list won't be invoked for the extracted credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1686) AuthenticationInfoPostProcessors aren't invoked for basic auth
[ https://issues.apache.org/jira/browse/SLING-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1686: - Assignee: Justin Edelson Fix Version/s: Auth Core 1.0.2 Affects Version/s: Auth Core 1.0.0 AuthenticationInfoPostProcessors aren't invoked for basic auth -- Key: SLING-1686 URL: https://issues.apache.org/jira/browse/SLING-1686 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.0 Reporter: Justin Edelson Assignee: Justin Edelson Fix For: Auth Core 1.0.2 If the built-in http basic authentication handler is used, the AuthenticationInfoPostProcessor list won't be invoked for the extracted credentials. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1677) Let AccessManager POST servlets return JSON
[ https://issues.apache.org/jira/browse/SLING-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman resolved SLING-1677. Resolution: Fixed fixed in r988382 Let AccessManager POST servlets return JSON --- Key: SLING-1677 URL: https://issues.apache.org/jira/browse/SLING-1677 Project: Sling Issue Type: New Feature Components: Servlets Affects Versions: JCR Jackrabbit Access Manager 2.0.6 Reporter: Eric Norman Assignee: Eric Norman Fix For: JCR Jackrabbit Access Manager 2.0.6 SLING-1336 added the ability to return a JSON response from the SlingPostServlet. The AccessManager POST servlets should have this capability as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1676) Let UserManager POST servlets return JSON
[ https://issues.apache.org/jira/browse/SLING-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Norman resolved SLING-1676. Resolution: Fixed fixed in r988381 Let UserManager POST servlets return JSON - Key: SLING-1676 URL: https://issues.apache.org/jira/browse/SLING-1676 Project: Sling Issue Type: New Feature Components: Servlets Affects Versions: JCR Jackrabbit User Manager 2.0.6 Reporter: Eric Norman Assignee: Eric Norman Fix For: JCR Jackrabbit User Manager 2.0.6 SLING-1336 added the ability to return a JSON response from the SlingPostServlet. The UserManager POST servlets should have this capability as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
