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