On 20 January 2015 at 14:15, Branko Čibej <brane_at_wandisco.com> wrote:
> On 19.01.2015 18:10, Ivan Zhakov wrote:
>> I've implemented proposed behavior in r1653032.
>>
>> On 18 January 2015 at 06:48, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>>> It would be nice if the the logged message should be different in that
>>> case, too. That is: there should be some indication, besides the
>>> different log level, that the subrequest-generated log event is
>>> "normal".
>>>
>>> That is, we don't want this:
>>>
>>> [debug] Access denied: /private
>>> [error] Access denied: /private
>>>
>>> But this:
>>>
>>> [debug] Hiding directory '/private' (Access denied)
>>> [error] Access denied: /private
>>>
>>> (Or some other log level instead of "debug" — I haven't thought about
>>> what log level would be appropriate.)
>> I agree that different log message would be nice to have, but there is
>> an issue: in mod_authz_svn we're not 100% sure that path will be
>> hidden. mod_authz_svn just answer the question whether access allowed
>> or not, but it doesn't know how this information will be used latter
>> at mod_dav_svn layer. May be different wording may fix this issue
>> though.
>
> I'm confused: when/why would mod_dav_svn ignore the result of an authz
> check?
>
I meant that hiding unreadable path is not only possible behavior for
mod_dav_svn. For example it may error out if it got unreadable path.
For example get-locks-report: attempt to get lock for unreadable path
will result requested failure (subversion\mod_dav_svn\lock.c:470). IMO
logging "Hiding path" will be confusing for user.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2015-01-20 12:57:58 CET