I recently uploaded an application on Google play store, this app connects to an online server using a php page. While I'm checking crashes and ANRs in developers console I found a crash written by a user, this user was able to trace the error like he was using the logcat in eclipse. He managed to get the link of the php page with the given parameters.
In my code, I deleted everything that is related to Log.
My question is how can I prevent users from tracing the errors in my application ?
If you do not want your exceptions (and hence exception stack trace) to be thrown from your application, set a global uncaught exception handler.
Thread.setDefaultUncaughtExceptionHandler()
Do it in your Application sub-class and handle the exceptions appropriately. Make sure you terminate process gracefully after you've handled the exception.
You could also opt for third-party crash reporting mechanisms like ACRA, Flurry, BugSense, etc.
Related
I have migrated from the old sentry SDK to the new Unified PHP SDK. Since then exceptions and errors are not logged to sentry and I get a Bad Request response.
I know this question is rather vague and open, but I mainly want to know if there are any known potential issues or if someone can point me in the correct direction to investigate further.
This is for PHP 7.3.7 running Wordpress 5.2 and Sentry SDK 2.1.2
It is a default implementation, no changes to Transport and we do not use any integrations. The error occurs in Sentry\Transport\HttpTransport::cleanupPendingRequests after WP has run its shutdown hook after an error has been triggered.
If I log messages manually to Sentry it works (most of the time? Just had one occurrence where it did not work just now...). But sending exceptions to sentry when they are thrown does not. The request is set up to be sent via a promise in sentry with the correct data, but finally, I get a Bad Request response back.
Since implementing the unifiened SDK we have had two calls to sentry that actually made it through, but I know there should be many more (sadly).
Looking at the request and building a curl command from it and running it works as expected.
(We also use the Javascript Browser SDK. That works as it should)
Sentry\init([
"dsn" => "__dsn__"]);
// works
Sentry\captureMessage("Hello", Sentry\Severity::debug);
// Will eventually end up returning a Bad Request response
throw new \Exception(":(");
I expect the Exception thrown in the example to end up in Sentry, but instead, I get a Bad Request Response.
As #HazA pointed out, it was a bug in the sentry/sentry package fixed in version 2.1.3
I've been looking for a Php logging framework throughout the web and I realized What is the need to use a PHP logging framework if Apache logs all interactions to the server?
1. Fine grain control over error messages
Relying on PHP to log all of its error in its error log, and Apache to log all its error in its error log is fine - but sometimes you need more details. For instance, something may throw an exception regarding a failed SQL query and the message might say something like SQLException: Could not retrieve XYZ data. However, we would also want to see the stack trace and SQL query that failed. We could opt to throw that in the exception message, but that deprives us of the fine grain control - I /don't always want that debugging detail.
2. Non-web Apache related tasks
I use PHP quite often for the CLI capabilities for cronjobs. Apache wouldn't be involved in this, and PHP would opt to send output to STDOUT. Logging any errors would allow me to review them later.
3. Logging things that aren't errors
I can imagine a scenario where you would want to see login times, but don't want to store it in the database. For instance:
8/21/16 7:48 - HPierce logged in
8/21/16 7:49 - HPierce logged out
These aren't errors, and parsing through Apache's access logs isn't practical to get this kind of user information.
I am a bit confused about how New Relic tracks errors in a php application.
Does the error level set in the application (with error_reporting()) matter for the php agent? Or does it still get all errors? Are there cases in which the php agent will not be able to gather errors?
The New Relic PHP agent hooks into PHP and any errors that hit the PHP error handler will be passed on to us. We typically ignore 4xx errors but anything else detected by PHP should get collected.
As we're listening for errors detected by PHP, changing the error level will also affect the level of errors New Relic can see. Ee will never report errors with a level of E_NOTICE or E_USER_NOTICE
Errors with the web-server which prevent the PHP extension from loading will not be tracked. There's also a known compatibility issue with Xdebug which prevents our agent from tracking errors.
As I am aware the best approach is to configure the agent using PHP agent (newrelic.ini) settings, the is the option newrelic.loglevel where you can set the log level. Although you can still use the error_reporting() to 'overwrite' those settings a relevant question / answer can be found here.
So as from my experience, there are some occasion that this is not working as I expected.
Some time when a fatal error occurred, the php agent was unable to track it. Also there where times that new relic was resetting the options I have put using the error_reporting() to the 'default' ones I have set via newrelic.loglevel.
Disclaimer : I have over a year to use new relic so this may be obsolete.
My opinion is not to mix the these two different ways of setting the error level and stick with the API that the php agent provides. I think that in most of the cases this is going to be enough
We have a web server that we're about to launch a number of applications on. On the server-level we have managed to work out the error handling with the help of Hyperic to notify the person who is in charge in the event of a database/memcached server is going down.
However, we are still in the need of handling those eventual error and log events that happen on application level to improve the applications for our customers, before the customers notices.
So, what's then a good solution to do this?
Utilizing PHP:s own error log would quickly become cloggered if we would run a big number of applications at the same time. It's probably isn't the best option if you like structure.
One idea is to build a off-site lightweight error-handling application that has a REST/JSON API that receives encrypted and serialized arrays of error messages and stores them into a database. Maybe it could, depending on the severity of the error also be directly inputted into our bug tracker.
Could be a few well spent hours, but it seems like a quite fragile solution and I am sure that there's better more-reliable alternatives out there already.
Thanks,
Why would using PHP's own error_log quickly become 'cloggered'? If all goes well you won't see many errors, correct?
Building a separate application, especially one using an API, just for error reporting adds a lot of possible points of failure for error logging if you ask me. You could perhaps build an application that checks the existing error logs on various servers / for different applications to be able to display them in a sort of error dashboard, so you can see when things are REALLY going wrong.
But I'm interested to see what others might suggest as well, I haven't thought about it thát much yet for myself.
We actually tail -f the server's php error log for various outputs, but also catch a lot of exceptions we throw ourselves. By throwing a custom exception, you could have it (based on priority of course) write to your database, a log stream, your bug tracker and/or mail those-responsible-for-that-module. Of course you should log why the exception was raised (for example, var_export()/serialize() the func_get_args() of the method you threw an exception in. Make the exception message huge, since it will save you.
In addition to this, we use Zend_Log where exceptions are a bit overkill (for example if the argument given to the method should be deprecated, we might log a bit of debug_backtrace() to see where that call came from. This could be extended to programs making graphs of expensive calls etc, but that's a sidenote :)
My best tip: know where your application could fail and where it can not, it's so much easier to search for that error. Make sure errors that are raised based on external services are interpreted as such.
... and to be honest, I think this kind of thinking (Error-API/-Service on app. level) is a bit weird: how could you prevent an error if you knew exactly how to handle it? Wouldn't you avoid/automatize it?
You could use set_exception_handler and set_error_handler to gather more specific info and report it in a way that will alleviate the 'cloggering'. You could do different files for each client or application, introduce your own codes that allow for easy processing by an error parsing script, etc.
I'd be careful about introducing extra code or infrastructure to the error-handling process. It needs to be super solid so you can trust the info you get. Reporting errors directly to the database? What about database connection errors? (and on and on)
What you're searching for are PHPs error handling functions: http://de.php.net/manual/en/ref.errorfunc.php
Especially interesting would be set_error_handler() that allows you to completely override PHPs internal error handler.
With that you can make your own logs per application / send emails to admins / save error info to a db / tell users that an admin has been notified or whatever.
By either returning true or false you can also control wether PHPs internal error handler should run after your function or not.
I've found out how to convert errors into exceptions, and I display them nicely if they aren't caught, but I don't know how to log them in a useful way. Simply writing them to a file won't be useful, will it? And would you risk accessing a database, when you don't know what caused the exception yet?
You could use set_error_handler to set a custom exception to log your errors. I'd personally consider storing them in the database as the default Exception handler's backtrace can provide information on what caused it - this of course won't be possible if the database handler triggered the exception however.
You could also use error_log to log your errors. It has a choice of message destinations including:
Quoted from error_log
PHP's system logger, using the Operating System's system logging mechanism or a file, depending on what the error_log configuration directive is set to. This is the default option.
Sent by email to the address in the destination parameter. This is the only message type where the fourth parameter, extra_headers is used.
Appended to the file destination . A newline is not automatically added to the end of the message string.
Edit: Does markdown have a noparse tag for underscores?
I really like log4php for logging, even though it's not yet out of the incubator. I use log4net in just about everything, and have found the style quite natural for me.
With regard to system crashes, you can log the error to multiple destinations (e.g., have appenders whose threshold is CRITICAL or ERROR that only come into play when things go wrong). I'm not sure how fail-safe the existing appenders are--if the database is down, how does that appender fail?--but you could quite easily write your own appender that will fail gracefully if it's unable to log.
Simply writing them to a file won't be useful, will it?
But of course it is - that's a great thing to do, much better than displaying them on the screen. You want to show the user a nice screen which says "Sorry, we goofed. Engineers have been notified. Go back and try again" and ABSOLUTELY NO TECHNICAL DETAIL, because to do so would be a security risk. You can send an email to a shared mailbox and log the exception to file or DB for review later. This would be a best-practice.
I'd write them to a file - and maybe set a monitoring system up to check for changes to the filesize or last-modified date. Webmin is one easy way, but there are more complete software solutions.
If you know its a one-off error, then emailing a notice can be fine. However, with a many hits per minute website, do not ever email a notification. I've seen a website brought down by having hundreds of emails per minute being generated to say that the system could not connect to the database. The fact that it also had a LoadAvg of > 200 because of of the mail server being run for every new message, did not help at all. In that instance - the best scenario was, by far and away, the watchdog checking for filesizes and connecting to an external service to send an SMS (maybe an IM), or having an external system look on a webpage for an error message (which doesn't have to be visible on screen - it can be in a HTML comment).
I think it depends a lot of where your error occured. If the DB is down logging it to the DB is no good idea ;)
I use the syslog() function for logging the error, but I have no problems writing it to a file when I'm on a system which has no syslog-support. You can easily set up your system to send you an email or a jabber message using for example logwatch or the standard syslogd.
I second log4php. I typically have it configured to send things like exceptions to ERROR or CRITITCAL and have them written to syslog. From there, you can have your syslog feed into Zenoss, Nagios, Splunk or anything else that syslog can talk to.
You can also catch and record PHP exceptions using Google Forms. There is a tutorial here that explains the process.