@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.

@onemillionplaces commented on March 11th 2022

Is there any update on this? I also got many entries in my PHP Log with "Error in Matomo: Your browser is not supported. Due to security issues your browser is not supported. Please upgrade to a newer version." What is the reason of this error? Is it coming from a bot? Because the timestamp showed my that I was not online the time the error happend.

@sgiehl commented on March 15th 2022 Member

Thanks everyone for the feedback. I had a closer look again. I guess the problem is, that we are showing the error page in that case, which is doing a direct logging here:
https://github.com/matomo-org/matomo/blob/6b12f37eb630d25dffa13e315b894abda80ed5af/core/testMinimumPhpVersion.php#L117
We will need to check again how we can prevent a logging in that special case

@onemillionplaces commented on March 15th 2022

Hallo Stefan. Kannst Du mir kurz erklären, wie es überhaupt zu dieser Fehlermedlung kommt? Ich bekomme die fast jeden Tag und das zu Zeiten, wo ich nicht online bin. Kommt das durch irgendeinen Bot? Kann man die Zeile 117 theoretisch einfach auskommentieren?

@sgiehl commented on March 15th 2022 Member

@onemillionplaces The Matomo UI doesn't support older browsers. So if someone tries to open the UI with an older browser Matomo shows an error (as it wouldn't work). The browser is detected based on the useragent. So in theory a bot could send an outdated useragent, causing this error.

@onemillionplaces commented on March 15th 2022

@sgiehl The error always occurred at times when I was not online. So it can only be a bot. Does it make sence to add a htaccess file in the Matomo folder with something like this:
RewriteCond %{HTTP_USER_AGENT} "com.google.GoogleMobile|Photon|SemrushBot|HeadlessChrome|Uptimebot|Wappalyzer|WhatsApp|NetcraftSurveyAgent|contxbot|Gluten Free Crawler|facebookexternalhit|Dalvik|MJ12bot|WordPress|Apache-HttpClient|MSOffice|Dataprovider|www.ru|RU_Bot|FunWebProducts|netEstate|IndustryIndexBot|scrapy|Excel|Exabot|DomainStatsBot|DomainCrawler|Microsoft Windows Network Diagnostics|MegaIndex|oBot|spbot|AlphaBot|TinEye-bot|MauiBot|BacklinkCrawler|Guzzle|ImplisenseBot|Daum|pycurl|PHPCrawl|VelenPublicWebCrawler|Sogou|IndeedBot|HubSpot|WebDataStats|Wget|zgrab|libwww-perl|DotBot|CCBot|MSIE 6.0|MSIE 10.6|MSIE 10.0|MSIE 9.0|MSIE 8.0|Media Center PC|Java|NortheasternSysNetBot|Nimbostratus|Ruby|ZDM|SafeDNSBot|Apache HttpClient|Xbox|SMART-TV|TagVisit|TelegramBot|aiohttp|ZoomBot|WISE|SmartTV|WLMHttpTransport|AhrefsBot|TO-Browser|DomainCheck|Indy Library|serpstatbot|HTTPie|mattermost|CloudFlare|Discordbot|Chromexplorer|WinHttpRequest|YandexVideo|YahooCacheSystem|Test Certificate Info|CATExplorador|WLMHttpTransport|Cakemix|CloudFlare-AlwaysOnline|Viber|adscanner|CheckMarkNetwork|CloudFlare-AlwaysOnline|Link Checker|python-requests|Cakemix|curl|Darwin|DataXu" [NC] RewriteRule .* - [F,L]

@James-Oakley commented on March 15th 2022

@sgiehl The error always occurred at times when I was not online. So it can only be a bot. Does it make sence to add a htaccess file in the Matomo folder with something like this: RewriteCond %{HTTP_USER_AGENT} "com.google.GoogleMobile|Photon|SemrushBot|HeadlessChrome|Uptimebot|Wappalyzer|WhatsApp|NetcraftSurveyAgent|contxbot|Gluten Free Crawler|facebookexternalhit|Dalvik|MJ12bot|WordPress|Apache-HttpClient|MSOffice|Dataprovider|www.ru|RU_Bot|FunWebProducts|netEstate|IndustryIndexBot|scrapy|Excel|Exabot|DomainStatsBot|DomainCrawler|Microsoft Windows Network Diagnostics|MegaIndex|oBot|spbot|AlphaBot|TinEye-bot|MauiBot|BacklinkCrawler|Guzzle|ImplisenseBot|Daum|pycurl|PHPCrawl|VelenPublicWebCrawler|Sogou|IndeedBot|HubSpot|WebDataStats|Wget|zgrab|libwww-perl|DotBot|CCBot|MSIE 6.0|MSIE 10.6|MSIE 10.0|MSIE 9.0|MSIE 8.0|Media Center PC|Java|NortheasternSysNetBot|Nimbostratus|Ruby|ZDM|SafeDNSBot|Apache HttpClient|Xbox|SMART-TV|TagVisit|TelegramBot|aiohttp|ZoomBot|WISE|SmartTV|WLMHttpTransport|AhrefsBot|TO-Browser|DomainCheck|Indy Library|serpstatbot|HTTPie|mattermost|CloudFlare|Discordbot|Chromexplorer|WinHttpRequest|YandexVideo|YahooCacheSystem|Test Certificate Info|CATExplorador|WLMHttpTransport|Cakemix|CloudFlare-AlwaysOnline|Viber|adscanner|CheckMarkNetwork|CloudFlare-AlwaysOnline|Link Checker|python-requests|Cakemix|curl|Darwin|DataXu" [NC] RewriteRule .* - [F,L]

Most of that will be irrelevant. The user agent is presenting as an older browser, hence the error. So trying to block legitimate bots with htaccess will not have any effect. They're also probably spoofing their user agent to look like a browser, and are using that of an outdated browser, so trying to block them using htaccess is unlikely to work as they'll be trying to evade such things.

Preventing logging that bypasses log-level preferences is the fix this needs.

This Issue was closed on March 30th 2022
Powered by GitHub Issue Mirror