On Mon, Oct 21, 2013 at 10:34 AM, Francis Daly <francis@daoine.org> wrote:
> On Mon, Oct 21, 2013 at 10:15:51AM -0400, B.R. wrote:
>
> Hi there,
>
> > Maybe someone wishes to log any attempt to access a protected ressource ?
> > Not sending credential is then considered as an 'error'
>
> Access log includes $status = 401.
>
> > Maybe someone only consider a 'void' attempt as an error if it's not the
> > 1st access in a short time.
>
> Access log includes $status = 401, and the user analysing the log can
> choose to ignore the first of a set in a short time.
>
> > The main problem here is that this message is generated when the
> > credentials are asked for, which is a normal flow of a use-case scenario
> > for a standard protected resource.
>
> Access log includes $status = 401 and $remote_user = -, probably.
>
> > Filtering for errors against a specific resources will then generated
> loads
> > of unmeaningful entries, potentially hiding interesting ones.
>
> Access log includes $status = 401 and $remote_user != -, probably.
>
> (There are cases when an "Authorization: Basic" header will include a
> value that shows as "-", but they probably aren't worth worrying about
> if you are looking for "normal" bad authentication attempts.)
>
Thanks for all those tips. The access log has all the required information
contained in it already, then.
> > 1°) Since cancelling sending credentials when requested generates 403,
>
> No, it doesn't.
>
> Cancelling sending credentials will usually get the browser to show
> you the 401 page that nginx sent on the previous request, which had
> invalid credentials.
>
Sorry for this, that was pure conjectures. Thanks for the explanation.
> > there must be a way for Nginx to differentiate 1st connection attempt to
> > the followings: can't that be used to avoid logging an error message on
> 1st
> > attempt (and log it in access log instead)? Downgrading this message
> > severity for this case.
>
> HTTP is stateless.
>
> Each request includes appropriate credentials, or it doesn't.
>
I know, that's why I was talking about creating some 'memory' (mapping
against IP addresses?)
You can drop the first-log-line-in-a-sequence in your analysis program,
> where you decide exactly what you mean by sequence. nginx should not
> decide what you consider a sequence.
>
Talking about what Nginx should or shoudn't decide for the user,
what about the error log entry when a 401 is accessed? :o)
As you mentioned earlier, this is already logged in the access log. What
about Maxim was suggesting: downgrading the message importance? Maybe that
would mean stopping logging that in the error logfile.
> > 2°) As an extra feature, is there a way for Nginx to remember (at cost of
> > memory) access attempts on (conf defined) short time, logging errors only
> > if a trigger made of (conf defined) multiple attempts is reached?
>
> A patch would probably be considered; but I suspect that it's going to
> be easier for whatever is reading the full log file to be told which
> lines to heed and which to ignore.
>
As stated, that's extra, and that's a new feature. More important trouble
must eat your time first.
That's not really adressing our issue best, so for now, a redifinition of
what Nginx should decide by itself or not
would probably be more effectual.
What about Maxim's proposition then? Is there something we missed about
mechanics in accessing protected resource?
---
*B. R.*
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
