On Wed, Nov 9, 2011 at 5:53 PM, Justin Edelson <jus...@justinedelson.com> wrote: > On Wed, Nov 9, 2011 at 7:56 AM, Felix Meschberger <fmesc...@adobe.com> wrote: >> Hi, >> >> Am 09.11.2011 um 15:41 schrieb Markus Joschko: >> >>> On Wed, Nov 9, 2011 at 3:11 PM, Felix Meschberger <fmesc...@adobe.com> >>> wrote: >>>> Hi, >>>> >>>> Am 09.11.2011 um 12:56 schrieb Markus Joschko: >>>> >>>>> With the most recent changes (SLING-2274) I can again use the CLI >>>>> client over davex, >>>>> but only when the anonymous user is enabled. As soon as I disable it, >>>>> I again have the problem with the repository descriptor retrieval. >>>> >>>> Hmm, this is not how it is intended to be. The davex bundle registers a >>>> dummy service which instructs the Sling Authenticator to not request >>>> credentials if missing and thus pass through anonymously if credentials >>>> are not preemptively provided. >>> >>>> >>>> So, you should be able to do what you want. >>>> >>>> What request do you do to try to get this information (excuse my ignorance >>>> here ;-) ) >>> >>> I just try to connect with the standard command line utility via davex >>> to the repository. >>> >>> java -jar jackrabbit-standalone-2.3.1-SNAPSHOT.jar --cli >>> http://localhost:8080/server >>> >>> With the enabled anonymous user everything is fine and I can >>> logout/login with admin. >>> With the anonymous user disabled I still can login but I can not do >>> any writes as the davex layer couldn't properly detect the >>> capabilities of the repository. >>> >>>>> >>>>> However I have a customer requirement that is: Nobody should be able >>>>> to login in the web UI with anonymous/anonymous. >>>> >>>> Agreed. >>>> >>>>> And AFAIK that can only be achieved by disabling the anonymous user. >>>>> Or am I wrong? Is there another way to forbid login of the anonymous >>>>> user. >>>> >>>> Well, with this setting we can prevent requests without credentials to >>>> pass by the Sling Authenticator. But we cannot prevent someone coming with >>>> the anonymous credentials from logging in. This has to be configured in >>>> the repository IIUIC. >>> >>> Oh sorry. With "disabling the anonymous user" I do not mean the flag >>> on the authentication service but using the usermanager to disable the >>> user in the repository. That is what I do and what prevents the davex >>> servlet from working properly. >>> >>> That's because the request for the repository descriptors has no >>> credentials included. So the anonymous user is used to fetch the >>> descriptors. If this user is disabled, >>> it is no longer possible to return a meaningful result. However having >>> the anonymous user enabled also allows everybody to login as >>> anoymous/anoymous. >>> >>> The original jackrabbit davex servlet has the >>> init.missing-auth-mapping parameter to specify another user that can >>> be used in case no credentials are provided. However that does not >>> work with the sling authentication in place >>> (https://issues.apache.org/jira/browse/SLING-2256) >> >> I think this explains a lot ... With using the Sling Authenticator we of >> course don't use the authentication support built into the DavEx library. >> Therefore the missing-auth-mapping has not influence whatsoever. >> >> Now, in the context of Sling, I hold that using the Sling Authentication >> mechanism is the right thing todo. But I understand, that Jackrabbit assumes >> a different POV.... >> >> This brings me to the following conclusion: Our Davex bundle in fact just >> adds OSGi integration as a single class and embeds two Jackrabbit libraries: >> jackrabbit-webdav and jackrabbit-jcr-server. >> >> How about adding the OSGi helper methods to the Jackrabbit >> JcrRemotingServlet and convert the libraries into bundles. So they are not >> part of Sling any longer. > > I'm not in favor of abandoning the DavEx->Sling Auth integration this > for two reasons: 1) as Carsten noted in one of his JIRA comments, > there are browser-based DavEx applications which depend upon Sling > Authentication to work seamlessly and 2) we lose out on the use of the > AuthenticationInfoPostProcessor infrastructure. > > In addition, I suspect that while the requirements of the DavEx > servlet with respect to Sling Authentication are not entirely unique > and that *if* there are changes required in Sling Authentication to > support the DavEx servlet will benefit other use cases. > > I'm convinced the problems are entirely solvable and I'm not ready to > throw in the towel quite yet. I may change my mind :) > > That said, as a short term solution to the issue Markus is having, I'm > perfectly fine with rollback SLING-2167, reapply the change described > in SLING-2256, and releasing DavEx 1.1.0.
Mhm, this removes the sling authentication support for now, or? But indeed, that would solve my problem. > > Justin > >> >> The price to pay is, that authentication for this does not go through Sling >> and does not benefit from Sling's central configuration and setup. >> >> Regards >> Felix >> >>> >>> Regards, >>> Markus >>> >>> >>> >>> >>>> >>>> Regards >>>> Felix >>>> >>>>> >>>>> Thanks, >>>>> Markus >>>> >>>> >> >> >
