Authentication error or maybe it isn't? - no user/password was provided

[B.R.]

On Mon, Oct 21, 2013 at 10:34 AM, Francis Daly <francis at 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131021/a9004b0c/attachment-0001.html>