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.)

> 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.

> 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.

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.

> 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.

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx