jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Joschko <markus.josc...@gmail.com>
Subject Re: Anonymous user
Date Thu, 10 Nov 2011 09:26:41 GMT
Hi Angela,
seems fine to me. All my headaches are caused by request from the
client where I can not pass credentials.
If this is skipped, I am fine.


On Thu, Nov 10, 2011 at 9:03 AM, Angela Schreiber <anchela@adobe.com> wrote:
> hi markus  (and including jackrabbit-dev as this doesn't really belong to
> the sling list)
>>>> 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.
>>> IIUC this is because although there was a change in Jackrabbit
>>> (https://issues.apache.org/jira/browse/JCR-3076) to handle the case
>>> when the repository descriptors weren't available, it handles only 401
>>> or 407 error codes. I haven't checked Felix's most recent changes, but
>>> last I checked, it resulted in a 403 error code.
>> Prior to JCR-3076 it was not even possible to connect to a repository
>> if it was protected by the sling authenticator (e.g. by a custom login
>> page).
>> The patch solves the "detection" of the repository.
>> The problem with the descriptors is mentioned by Jukka:
>> "A more complete fix would also modify the webdav server to always
>> allow repository descriptor report requests without authentication,
>> but that would require non-trivial changes to the way requests are
>> currently being processed in the webdav server. Doing that would allow
>> clients to access repository descriptors even if repository access
>> otherwise is blocked only to authenticated clients. Let's handle that
>> as a possible followup issue."
> if i am not mistaken we could fix that rather easily on the
> client (jcr2spi) side. currently SessionImpl#isSupportedOption
> assumes that the descriptors have been successfully loaded.
> i would suggest that we change that code such that it only evaluates
> the descriptor if the descriptor if present and otherwise returns true.
> in the latter case the fact that a given SPI implementation does not
> support a given feature will only be detected upon passing the
> call for processing to the SPI. this is pretty straight forward for
> all the workspace operations and maybe a bit inconvenient for Session#save.
> but most probably that would solve your problem.
> what do you think?
> angela
>>>>>> 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
>>>>> 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)
>>>> Regards,
>>>>  Markus
>>>>> Regards
>>>>> Felix
>>>>>> Thanks,
>>>>>> Markus

View raw message