This fixes a bug where only one tag gets used when multiple tags have
been configured (e.g. different tags for 'syslog_tag' and 'syslog_tag_audit')
Signed-off-by: Kent Delante <kent.delante@proton.me>
false is expected, not null. The changed caused "user" in the log files
to be false instead of "--", which is breaking behaviour.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Louis <louis@chmn.me>
Co-authored-by: Côme Chilliet <91878298+come-nc@users.noreply.github.com>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
There is the `Psr\Log\LogLevel` class defining loglevel constants,
to be fully compatible we should at least support those logging levels.
Moreover this is the last part that was still required from `ILogger` interface,
as we did not have alternatives for the loglevel constants.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* `PublicSessionController create` receives a share token.
* The others receive the parameters for a text session:
`document_id`, `session_id`, `session_token`.
Even though these are relatively short lived
they could be used to retrieve content from the document when leaked.
Signed-off-by: Max <max@nextcloud.com>
This will avoid running into a Nesting level too deep error as the
encodeArg calls will limit potential recursive calls on the arguments to
a nesting level of 5
Signed-off-by: Julius Härtl <jus@bitgrid.net>
It was only logged when an exception was provided or when using
logData (which is not being much used).
We make sure the interpolated parameters are not logged.
Only tested with file write logger, but shouldn't work differently.
Crash reporters always had the context.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
This will make sure that nested objects or arrays do not cause exceeding
the maximum nesting level of functions when parsing arguments of an
exception trace
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Applies the suggested transformation mentioned in
https://www.php.net/manual/en/migration80.incompatible.php,
> The @ operator will no longer silence fatal errors (E_ERROR,
> E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR, E_RECOVERABLE_ERROR,
> E_PARSE). Error handlers that expect error_reporting to be 0 when
> @ is used, should be adjusted to use a mask check instead
The new code still works on PHP 7, as error_reporting() already
returns 0 when diagnostics are suppressed.
This fixes https://github.com/nextcloud/server/issues/25807 in PHP 8.0.
For PHP 7.x, https://github.com/nextcloud/server/pull/22243 suppresses
the E_NOTICE message from the second session_start() call with the error
suppression operator @, and thus those E_NOTICE messages are still
logged in PHP 8.0.
See also https://github.com/nextcloud/server/issues/25806
Signed-off-by: Chih-Hsuan Yen <yan12125@gmail.com>