Avoid multiple log files in multi-language environments

[jensschuppe]

Overview

Fixes dev/core/3491

Before

Multiple log files (one per language) in multi-language environments when using path prefixes.

After

Only one log file per environment.

Technical Details

Removes language path prefixes from user framework base URL when generating log file name hash.

Comments

I dird not have the time to thoroughly test this, but wanted to provide it as a PR as requested by @jaapjansma in the issue.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[mlutfy]

The languageNegotiationURL function is weird (well, the remove args), but this change is otherwise harmless, and I have to admit that the multiple log files are really annoying/confusing. +1 on concept.

I would have recommended to remove the URL from there completely, but then everyone's log files will be renamed, and that will annoy people to. Then again, maybe simpler code is worth it.

@sluc23 @seamuslee001 this might interest you. Opinion on keeping the URL, or drop?

[sluc23]

+1 to have only 1 ConfigAndLog/CiviCRM.*.log in multi-languages sites
+1 to remove the url completely.. i never understood why log files had such a complex name.. it does not add any value adding that hash to filename in my POV..

[totten]

Soft +1 for common log file in the multi-language sites (using this patch -- ie using the common base URL).

IMHO, long-term, we should probably try to replace (phase-out) generateLogFileHash() with some kind of constant in civicrm.settings.php... i.e. a value that is (a) truly random, (b) independent of DSN and site-key, (c) able to rotate on its own cycle, and (d) possible to customize.

However.... within the rubric of generateLogFileHash(), there is an argument for including some kind of URL. Recall that generateLogFileHash() is expected to be both stable and hard-to-guess. It's cobbled together from multiple entropy sources, but (individually) each source of entropy has issues:

1. dsn should have a strong password component in most architectures. But some systems have silly/obvious values (mysql://root:root@localhost:3306/civicrm - which the implementer may justify by using containers/firewalls/sockets/etc).
2. CIVICRM_SITE_KEY should be a long secret. But it can be silly/obvious value (eg if it wasn't set -- NO_SITE_KEY), and sometimes it can be readily discovered (eg if you have mobile or desktop integrations).
3. userFrameworkBaseURL is never secret, but it is always unique.

In the worst case, dsn and CIVICRM_SITE_KEY are both weak/common values, and the checksum of 1+2 would also be weak/common. You could simply search Google for a couple constants -- and find logs for poorly-configured sites. Adding the URL makes the checksum unique - which frustrates Google searches.

So... 1+2+3 is more secure than just 1+2, but it's still not particularly secure (overall). IMHO, it would be more robust (secure+simple) to have this random value pre-generated and stored in civicrm.settings.php.

[mlutfy]

OK, so I guess +1 from Tim on keeping the URL in there.

Which makes this PR merge-ready? Any objections?