On Nov 9, 2011, at 9:10 AM, Markus Joschko <[email protected]> wrote:
> On Wed, Nov 9, 2011 at 5:53 PM, Justin Edelson <[email protected]> > wrote: >> On Wed, Nov 9, 2011 at 7:56 AM, Felix Meschberger <[email protected]> wrote: >>> Hi, >>> >>> Am 09.11.2011 um 15:41 schrieb Markus Joschko: >>> >>>> On Wed, Nov 9, 2011 at 3:11 PM, Felix Meschberger <[email protected]> >>>> 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. > Yes 'for now' being the operative term > >> >> 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 >>>>> >>>>> >>> >>> >>
