New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't log an error when not supported browser is used #17738
Comments
Also, it should not cause a |
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....
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? |
@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. |
@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? |
@bisoldi Yes. It's only thrown by the Matomo UI and not thrown while tracking. |
@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? |
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. |
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! |
@bisoldi maybe try asking further questions on our forum. We are only handling specific bugs or feature requests here. |
@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. |
Hello, please, I have exactly this issue on PHP error log, since the last version, full of lines in some languages like this: How to prevent? Thanks |
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? |
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 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 |
Which log_level have you configured in Matomos |
there's anything about log_level in that file. Do I need to add a line there? Thanks |
If there is nothing in your config it should use the default from global config, which is |
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 |
There must be some problem with ExceptionHandler.php, it seems that it catches the exception at default, ignoring Log::DEBUG, so it runs please check, thanks |
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. |
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. |
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: matomo/core/testMinimumPhpVersion.php Line 117 in 6b12f37
We will need to check again how we can prevent a logging in that special case |
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? |
@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. |
@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: |
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. |
Seeing thousands of these logs on our cloud:
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 inExceptionHandler::dieWithHtmlErrorPage()
.The text was updated successfully, but these errors were encountered: