Branko Čibej wrote on Tue, Jan 20, 2015 at 13:13:05 +0100:
> On 20 Jan 2015 12:54, "Ivan Zhakov" <ivan_at_visualsvn.com> wrote:
>
> > 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.
> >
> Right, understood. So 'hiding path" is not wording that mod_authz_svn can
> use, but we can come up with some authz-specific wording that's different
> from the current "access denied," right?
How about:
is_subreq_bypass is true:
"Access denied (subrequest=0)"
is_subreq_bypass is false:
"Access denied (subrequest=1)"
That's more or less the least imaginative thing possible, but I think
it's better than having to ask people whether their "Access denied"
error message was at [info] or at [error].
WDYT?
Received on 2015-01-24 15:39:30 CET