access_log to track failed logins

AJ Weber aweber at comcast.net
Wed Dec 19 02:05:30 UTC 2012


>> I have a login page that redirects (actually appends the parameter
>> "?error=true" to the URL and lets the user try again).
>>
>> I was trying to re-define "access_log" with a full path and (for now)
>> "combined" to a separate file in that location
> nginx chooses configuration based (primarily) on the "location", which
> is the local part of the request, excluding query string.
>
> So whatever location matches /my/login/page will also match
> /my/login/page?error=true.
>
> Does that explain why your initial attempts did not do what you expected?
No, unfortunately it doesn't.  I copied the "GET" from the "usual" 
access log exactly.  Thus, I know the call is being made, because it's 
being logged in the normal log, and I'm pretty sure I have the right 
location string, because I copied it right out of the log.

Do I need to escape anything?  I've tried = and ^~ matching and neither 
seems to catch it.

>> This doesn't seem to work at all.  An empty log gets created at startup,
>> but nothing ever gets written there.  Is it because the access logging
>> is already done by the time the location is determined?
> No, the access logging is done in the context of whichever location the
> request finishes in. It doesn't appear in your error=true log, because
> a request like /my/login/page%3Ferror=true was not made.
>
> (As a test, make a request like that, and you should see it in the
> new file.)
Yes, as I mentioned above, my requests DO get logged (always).  They 
just don't go to the log I want them to.

>> How can I somehow log when someone accesses the "login" page with the
>> "error=true" parameter on the URL?
>>



More information about the nginx mailing list