[geeklog-devel] access.log

[Vincent Furia]

Dirk Haun wrote:

>I'd like to propose that we re-think the use of the access.log file.
>Currently, it is pretty much useless (open yours and see for yourself),
>as all it lists are session ids and date stamps about someone logging
>out. Since the session id has been gone from the gl_sessions table by
>then, this information doesn't really help with anything.
>
>  
>
I agree, let's get rid of that logging.  I always wondered why the 
session ids were logged on log out.

>Now, I don't want us to log when people are logging in and out, as there
>is no reason to collect that information (and especially not in a file).
>Geeklog currently stores the last time someone logged in, for the
>legitimate reason of trying to keep track if an account is (still) in use.
>
>(On a side note, I'd like to see some "housekeeping" tools being
>developed as addon-ons making use of that information, e.g. to weed out
>unused accounts after some time.)
>
>Back to access.log: When trying to access one of the admin pages without
>being an admin, you are told that this attempt had been logged. However,
>in almost all cases, it hasn't - I've only recently added this to CVS,
>after someone pointed it out in the forums.
>
>Since the error.log tends to be clogged with lots of messages, it would
>be hard to find any access violations in all that noise. So I'd suggest
>we use the access.log for that instead.
>
>  
>
This makes sense.  In fact, someone not familar with Geeklog would 
probably look in access.log for access violations first in any case.

>To save on code, COM_accessLog could be extended to automatically log the
>IP, user id (and name?) of the user that caused the violation in addtion
>to the time stamp it's already adding automatically.
>
>So what should be logged?
>
>- Any attempts at accessing the admin pages without proper authentication
>  (just what we already claim we're logging)
>- Attempts at doing something the user doesn't have proper permissions
>to, e.g.
>  trying to access a story without the proper permissions, or an
>  admin doing something they are not allowed to do (e.g. a Group Admin
>  trying to edit the Root group).
>- Failed login attempts, to see if someone is trying to hack accounts
>  
>
Another tangent: In the future, if we kept track of how many failed 
login attempts since last succesfull login, we could do some pretty cool 
stuff (like lock and possibly send email to the affected person and 
admin that a login has failed three times on an account).

>- anything else?
>
>What I want to avoid, though, is to collect too much (detailed)
>information or to give users the impression that they are being spied on.
>
>Comments?
>
>  
>
Sounds good to me Dirk.

>bye, Dirk
>
>
>  
>
bye... Vinny