manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Could an authority connection that is not working clash the search
Date Thu, 11 Jun 2015 15:33:35 GMT
Hi Karl,

thanks again: fast and smart ...

we are claiming that the call to the authority service simply takes  
too long and 503 is returned.

I agree fully that the authorization decision is up to the concrete  
authority connection.

We are talking about three individual implemented authority  
connections, namely:
- Confluence
- SharePoint
- and a Enterprise Content Management System

You hepled us very much by pointing us on the correct handling in case  
of 503, distinguishing between "incomplete" and "unauthorized". Thanks  
a lot.

Anyways a last remark: Couldn't be "unauthorized" a good default for  
MCF in case of 503?


Zitat von Karl Wright <>:

> Hi Rüdiger,
> Ok, I misunderstood -- I thought that Solr could not talk to the MCF
> authority service.  Instead you are saying that one particular authority
> may be down.
> If this is your situation, please note that the behavior of the individual
> authority connector has been carefully considered.  Specifically, depending
> on the particular authorization model used by the repository in question
> (e.g. whether deny authorization is possible), the authority may choose to
> interpret inability to contact the repository in either one of two ways:
> (1) responding with an "unauthorized", which basically shuts down any
> results back from solr, or "incomplete", which basically allows results to
> be returned but includes only open documents from that repository.  Doing
> anything else constitutes a security hole, I'm afraid.
> What's confusing to me is that in *either* situation, the results that Solr
> returns should be filtered accordingly, and a 503 should not be returned.
> If you are claiming that the call to the authority service simply takes too
> long in the case where 503 is returned, most authorities *do* support a
> timeout value that can be adjusted, and you would simply want to reduce
> that value for the authority in question.  But I need to emphasize that it
> really is up to the individual authority to determine if authorization for
> that authority is allowed, and we cannot institute any blanket policy for
> that reason.
> Can you tell me which authority is taking a long time?
> Karl
> On Thu, Jun 11, 2015 at 10:39 AM, <> wrote:
>> Hi Karl,
>> as any time... thanks for the quick reply.
>> The drawback of this solution is that the search will run in a
>> "non-authorised" mode: If one of the authority connections does not work,
>> we will have anonymous access only ...
>> The prefered solution would support authorised search for all authority
>> connections except the one that is not working.
>> kind regards
>> -Rüdiger
>> Zitat von Karl Wright <>:
>>  I believe you can set the socket timeout for the Solr plugin via plugin
>>> parameters.  I suggest you try that to limit the damage you'd get if the
>>> request could not be completed.
>>> Thanks,
>>> Karl
>>> On Thu, Jun 11, 2015 at 9:13 AM, <> wrote:
>>>> Hi there,
>>>> we have the following situation ...
>>>> When one of the configured authority connections does not get a response
>>>> from its service URL, the search results in a response with an error
>>>> (status 503).
>>>> What's hppening in the background:
>>>> The service URL is not reachable, being blocked by a firewall. At client
>>>> side: The Solr-XHR request is pending for long time and finally results
>>>> in
>>>> a 503.
>>>> The expected behavior would be, that the search is still working and does
>>>> not show results that are protected by this authority connection but
>>>> anything else.
>>>> Currently we are starting our analysis. So far I'm interessted if this
>>>> situation is known by anybody out there and or if there are any hints or
>>>> ideas to keep the serach alive even an authority connection is not
>>>> available at search execution time.
>>>> Thanks in advance
>>>> -Rüdiger

View raw message