Re: Fwd: Patch for user reporting in HTTP
"Bjorn L." <[email protected]>
| Newsgroups | gmane.comp.log.logwatch.devel |
|---|---|
| Message-ID | <[email protected]> |
The code is now in cvs, but using a new variable, called $HTTP_USER_DISPLAY. Which codes are displayed is now programmable. Your suggested use (code 401) is one of the examples; it needs to be uncommented to be functional. (Or more specifically, that line should be added to your local /etc/logwatch/conf/services/http.conf file if you want to preserve it across updates to Logwatch.) Mike Bremford wrote: > 401 is probably the best one to check, as anything else implies that the > user is authorized, at least as I understand it. If an authorized user > gets a 500 from a failing CGI script, that's still an authorized access > I think. > > If there's an error determining whether the user can be authorized (if > Apache gets the userlist from a database, for example), I'm not sure > what Apache does. > > Quite right on "logged in" - "Users authorized" is probably the most > accurate description. Feel free to tweak the text, or would you like me > to send another patch? > > Cheers... Mike > -- > ----------------------------------------------------- > Mike Bremford - CTO [email protected] > Big Faceless Organization http://bfo.co.uk > > > On 16 Feb 2007, at 21:16, Bjorn L. wrote: > >> Mike Bremford wrote: >>> Hi Kirk and/or logwatch-patches >>> I sent this through a few months back but didn't get a response, and >>> I've just noticed it's not in CVS. >> >> It looks like it didn't get through the mailing list the last time. >> >>>> 1. We need to keep track of who's logging in to our HTTP server >>>> from where, so I've patched "http" to tot this up in the same way >>>> as for requests with error response codes. >> >> Two questions: >> >> - Yuo test for status code 401. Should it consider all non-error >> accesses (status code < 400)? Or only the successful ones (status >> code >= 200 && status code <300)? >> >> - The term "loggin in" is ambiguous and may infer something else. >> Either "successful accesses" or "non-error accesses" (depending >> on the answer to the first question) may be more suitable. >