Translate login events only on GLPI UI

[eduardomozart]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• [] I have added tests that prove my fix is effective or that my feature works.
• [] This change requires a documentation update.

Description

• It fixes # (issue number, if applicable): https://forum.glpi-project.org/viewtopic.php?id=283065
• Here is a brief description of what this PR does:

This PR logs the login events in English in the DB and the files\_log\event.log instead of relying on the Web user browser language. This allows for implementing Fail2Ban (1, 2) and other security mechanisms independent of the language that the user logs in to GLPI to log and protect against brute-force attacks, while still providing the translation to the user in the GLPI UI.

Screenshots (if appropriate):

But in the Administration > Logs > Event Logs, it's shown in the current GLPI user language:

In Administration > Logs > events.log, it's shown in English since the log information is saved in English in the DB and the event.log log file.

[cedric-anne]

IMHO, event logs should always be translated in the GLPI default language (defined at installation), or never translated at all.
I think all Event::log() occurences have to be handled the same way, but I am not sure your proposal would be easy to maintain.

[trasher]

I'm not in favor of that change.

What GLPI logs has never been designed to be used in a log analyzer; that would be a complete distinct feature to be really reliable.

[eduardomozart]

It’s not only useful for a log analyzer.
As the GLPI logs the login attempts in the Web user browser language instead of English, in a multiuser environment (e.g., multinational companies), an admin may be missing security events because he/she don’t understand a specific language in the logs. It can also help IT teams to easily figure out the reason that a user complains that they can’t access GLPI through the logs. It can also be used for other tools, like IDS/IPS and security analyzers like Wazuh and Zabbix.
Even if neither of those tools is used, as GLPI pretends to be a multi-language software, it should default to English on the DB and its log files and translate to the end user based on the GLPI UI user language. In the past, there was an issue where logs were being written in the native language to the glpi_logs DB table, and a similar PR has been approved to fix it.
I don’t think that to use the default GLPI language selected during installation is the better approach (even it being a slightly better approach than today) because it will still maintain the issue that exists nowadays, regarding logs: there’s no standard. If you search for “fail2ban GLPI” on Google, you will find users complaining about non-standard strings on GLPI forums, and some tutorials use English or French strings to interpret login attempts. I do believe that in DB and the “log” function of the Event class, it should always use English and translate the string to the end user based on its current GLPI UI language. I do believe this case is similar to the Administration > General > System tab that contains system information: it’s always in English, as users of other languages may parse that information for troubleshooting, like the GitHub issues tracker.
If a translation is not viable, it could at least assign a different code to failed login attempts. Actually, all login messages are assigned with the “[login] 3” prefix from the log() PHP function and GLPI DB.
At least GLPI seems to return a different HTTP code (400 Bad Request) on Apache/NGINX access log; theoretically, it seems possible to detect failed login attempts/brute-force attacks similar to https://github.com/nofusscomputing/ansible_role_glpi/blob/2865f3c65685ea0e24b349c3e53c0126322446b9/templates/fail2ban.filter-api.conf
Another possibility would be bypassing the placeholders (e.g. %1$s and %2$s) as an array to the function log of the Event class, e.g. public static function log($items_id, $type, $level, $service, $event, $params) ($params was added) and we could translate the message to be saved on log function, so we can translate the message on DB (as today) but not translate it when saving to event.log file, but I agree with cedric-anne on not translating them on DB and event.log file.