Add a apache log entry when user fails to authenticate about glpi HOT 14 CLOSED

thanks for the commit :)

from glpi.

I think using direct error_log (to apache log) is not the correct solution.
In GLPI we "never" use error_log directly

We only use logDebug (to php-errors.log) or logInFile (to any file)

Adding such error_log imply another file to manage / supervize.

from glpi.

OK. You're right for log_error function.
Even so, i think logging "login errors" could be an improvement.

We can add a new file login_error.log filled by a Toolbox::logInFile('login', $sg); to manage this information.
Better, we can condition the writing by a check on use_log_in_files configuration var.

Imo, others existing files in _log arent legit for this new content.

from glpi.

Yes but better to have info on only one line : date + IP

from glpi.

Even so, i think logging "login errors" could be an improvement.

I never say I disagree with the feature ;) only with implementation :p

from glpi.

Perhaps even simpler to log in a event_log file all records added in glpi_events

from glpi.

Ok like this ?

from glpi.

I not agree with the solution. In your commit ALL events are recorded and the log file will be huge for a big society.
For me you must only record failed events

from glpi.

Sure but filtered by two options :

• event_loglevel (Event::prepareInputForAdd cancels the event db add and log)
• use_log_in_files (Toolbox::logInfile don't store on disk if options disabled)

System admin can also manage all log files with a logrotate (I think this should be highly recommended in documentation, for all log files, your opinion ?)

from glpi.

The request was for failed login, not for all events.
A filter on level 1 should be apply

from glpi.

I reverted previous commit pending a decision regarding this issue.

Sincerely, i think logging events won't increase disk usage dramatically .

On the bigger instance i know, with event_loglevel = 5 (full), glpi_events table contains 20K entries per month.
An event line should be arround 150 Bytes.
So a disk increase of 3mBytes per month.

This log could be archived and deleted by logrotate or by glpi crontask "circularlogs".

Can you provide amount of line added per month in your context for estimation ?

from glpi.

@yllen, PR is up to date with your advises.
If it's ok for you, i'll merge this

from glpi.

OK for me

from glpi.

The original Redmine issue's goal was to be able to use fail2ban, which #58 does not permit.
The event.log file format is incompatible with fail2ban which requires a "timestamp" on the event line...

Can theses authentication failures event be sent to other, more fail2ban compliant, locations? I didn't find any corresponding configuration setting in GLPI.

from glpi.