@tsteur opened this Issue on July 6th 2021 Member

Seeing thousands of these logs on our cloud:

ERROR Piwik\ExceptionHandler[2021-07-05 23:57:59 UTC] [52b29 demo-proxy.innocraft.cloud] /core/SupportedBrowser.php(68):

Your browser is not supported.

Due to security issues your browser is not supported. Please upgrade to a newer version.

#0 /core/SupportedBrowser.php(54): Piwik\SupportedBrowser::throwException() #1 /core/FrontController.php(423): Piwik\SupportedBrowser::checkIfBrowserSupported() #2 /core/dispatch.php(31): Piwik\FrontController->init() #3 /index.php(25): require_once('/c...') #4 {main} | ERROR Piwik\ExceptionHandler[2021-07-05 23:57:59 UTC] [52b29 demo-proxy.innocraft.cloud] /core/SupportedBrowser.php(68):

Your browser is not supported.

Due to security issues your browser is not supported. Please upgrade to a newer version.

#0 /core/SupportedBrowser.php(54): Piwik\SupportedBrowser::throwException() #1 /core/FrontController.php(423): Piwik\SupportedBrowser::checkIfBrowserSupported() #2 /core/dispatch.php(31): Piwik\FrontController->init() #3 /index.php(25): require_once('/c...') #4 {main}

This may be caused for example by our monitoring tools or so. Could we adjust the logic to not log such an error when this exception happens?

I suppose we can catch NotSupportedBrowserException and make it not log. I'm thinking this would need to be done in ExceptionHandler::dieWithHtmlErrorPage().

@mpdude commented on July 14th 2021

Also, it should not cause a 500 status code for the user, but rather something from the 4xx range.

@bisoldi commented on July 15th 2021

We're now seeing this as well. I'm confused as to how this error comes to be exactly. If I can enumerate my questions regarding this....

  • What is the "security issue exactly"?
  • Is this an exception that's being thrown within the browser, transmitted to the server and then logged out?
  • If the Matomo client-side doesn't support the browser, then how is it even able to transmit the error?

Some kind of call made its way from the browser to the server, in order to log this error. Why does Matomo reject it in the form of a server-side error log rather than simply tracking it as a metric?

@sgiehl commented on July 15th 2021 Member

@bisoldi the exception is thrown server side when someone tries to request Matomo UI with a user agent header containing a browser that is marked as not supported. This is not checked client side.

@bisoldi commented on July 15th 2021

@sgiehl So, to be clear this is NOT related to Matomo event tracking for our web application...this is being thrown while someone is accessing the Matomo console?

@sgiehl commented on July 15th 2021 Member

@bisoldi Yes. It's only thrown by the Matomo UI and not thrown while tracking.

@bisoldi commented on July 15th 2021

@sgiehl Thank you so much! I'm trying to figure out how to enable error/debug logging (server side) thrown while tracking. Can you point me in the right direction?

@sgiehl commented on July 15th 2021 Member

If you are look for tracking failures you can simply look in the Matomo Admin > Diagnostics > Tracking Failures. If there aren't any failures listed all requests were tracked correctly. If not you need to look at the error log for that specific time.

@bisoldi commented on July 15th 2021

Thank you again. Last question, I promise, before I open a new ticket with any other questions....If we enable debug = 1 in the matomo.ini.php config file, will that simply print errors to the console? We have someone on staff who is not finding her activity being tracked when it should be, and there is nothing listed under "Tracking Failures". We're hoping to get some additional information on it.

Really appreciate your help!

@sgiehl commented on July 15th 2021 Member

@bisoldi maybe try asking further questions on our forum. We are only handling specific bugs or feature requests here.
Note: There are plenty of reasons why something might not be tracked. Most common reasons are ad blockers or do not track setting in the browser.

@bisoldi commented on July 15th 2021

@sgiehl I'll definitely do that. Not trying to ask you for help (here) in trying to track down a reason, just wanted to know if debug = 1 will print to the console or splash something in the UI? Thanks.

@7starsone commented on October 26th 2021

@bisoldi maybe try asking further questions on our forum. We are only handling specific bugs or feature requests here. Note: There are plenty of reasons why something might not be tracked. Most common reasons are ad blockers or do not track setting in the browser.

Hello, please, I have exactly this issue on PHP error log, since the last version, full of lines in some languages like this:
... Error in Matomo: Your browser is not supported.Due to security issues your browser is not supported. Please upgrade to a newer version.

How to prevent? Thanks

@sgiehl commented on October 26th 2021 Member

Since the last release those "errors" should only be logged on debug level.

@7starsone commented on October 26th 2021

Since the last release those "errors" should only be logged on debug level.

Thanks for your answer. I didn't change anything, so where's this option, please?

@sgiehl commented on October 26th 2021 Member

If you are not logging on a DEBUG level, those errors shouldn't appear anymore once you have updated to the latest release.

@7starsone commented on October 26th 2021

If you are not logging on a DEBUG level, those errors shouldn't appear anymore once you have updated to the latest release.

my php error reporting is
error_reporting = E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR

previously, I didn't read those lines on php error log, I don't have any to update since is the last version, so it's something in your code and please, I don't need those lines on log, is a mess at the moment. Thank you

@sgiehl commented on October 26th 2021 Member

Which log_level have you configured in Matomos config.ini.php?

@7starsone commented on October 26th 2021

Which log_level have you configured in Matomos config.ini.php?

there's anything about _loglevel in that file. Do I need to add a line there? Thanks

@sgiehl commented on October 26th 2021 Member

If there is nothing in your config it should use the default from global config, which is WARN

@7starsone commented on October 26th 2021

I checked the global.ini.php and it was WARN, even changing it to ERROR (example) on php error log is the same. Probably something in your code. Please, can you show me which file is affected and the relevant lines of code? Thanks

@7starsone commented on October 27th 2021

There must be some problem with ExceptionHandler.php, it seems that it catches the exception at default, ignoring Log::DEBUG, so it runs self::logException($exception);

please check, thanks

@James-Oakley commented on December 11th 2021

Just to confirm, on 4.6.1, log_level in global.ini.php is set to WARN, there is no log_level entry in config.ini.php, and I'm getting PHP error log entries as described here.

This Issue was closed on September 14th 2021
Powered by GitHub Issue Mirror