Can I hide the path in php error using .htaccess
Example:
Notice: Undefined variable: hello in C:\xampp\htdocs\mysite\index.php on line 3
I want to hide the path using .htaccess or print something let me know if there is an error without print the path of the page:
Notice: Undefined variable: hello on line 3
or
Notice: Undefined variable: hello
or
There is error in your page
Edit :
I put this lines in my .htaccess
But I can't access to my site. There is error "Internal Server Error"
How Can I fix that
# supress php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0
PHP’s error messages are not meant for users but for developers only.
So for a production environment, you should disable display_errors to avoid information disclosure:
Note: [display_errors] is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).
Instead, you should show generic error messages to your users that do not unveil anything of the internals and only log the error messages (see log_errors and error_log):
Note: You're strongly advised to use error logging in place of error displaying on production web sites.
And if you really want to modify PHP’s error messages, you can use set_error_handler to set a custom error handler.
See also OWASP’s Development Guide on “Error Handling, Auditing and Logging” for further information.
You cannot change the messages : those are generated by PHP, and that's the way they are.
But you can prevent them from being displayed to your website's users -- and still log them, for your own usage.
For that, see :
display_errors : to prevent errors from being displayed to the page's output
log_errors : to indicate that errors should be logged to a file
error_log : to specify to which file errors will be logged to.
Of course, that doesn't prevent you from fixing as many causes of notices / warnings / errors as possible ;-)
Get rid of all that useless stuff.
php_flag display_errors 0
alone will be enough.
If error persists, check server's error_log for the error message
Related
I'm using NGINX with PHP-FPM in seperated Docker containers. I want to get errors only to stderr, so that I can collect them on a centralized log-server. Problem is: I'm using WP and seems to have some not well written plugins. They work but cause warnings like this:
2017/06/17 01:16:08 [error] 7#7: *1 FastCGI sent in stderr: "PHP
message: PHP Warning: Parameter 1 to wp_default_scripts() expected to
be a reference, value given in /www/wp-includes/plugin.php on line 601
Example script for testing, which should give me a fatal error in the stderr:
<?php
not_existing_func();
PHP-FPM was configured to log errors to stderr like this:
[global]
log_level = error
error_log = /proc/self/fd/2
I'm wondering that this gave me nothing in the script above. Just after I switched the log_level to at least notice, I got the exception on the console of the docker container:
[17-Jun-2017 01:45:35] WARNING: [pool www] child 8 said into stderr:
"NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to
undefined function not_existing_func() in /www/x.php:2"
Why the hell is this a notice? For me we've clearly a fatal error here like the message indicates, cause the script can't continue (and we get a 500 error in the browser, of course). It can't be true that I have to set log_level to notice so that I don't miss fatal errors which are delcared as warnings. And simultaneously, my logs get filled with trash warnings from wordpress themes, plugins and so on, that I haven't developed and I don't want to fix for update reasons...
I tried a bit and found out that log_errors in php.ini is essential for PHP-FPM to get any information. But the log level from error_reporting seems wired too. For testing purpose, I used the following configuration:
display_errors = Off
log_errors = On
error_log = /proc/self/fd/2
;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
error_reporting = 0
Result: I got notices, but NO info about my fatal error...
First of all, I learned that I was wrong: Wordpress is the root cause for this issue, not PHP directly. It's a known fact that WP manipulates the error_reporting when debugging is enabled, so I tried to define WP_DEBUG as false in my config; BUT even having this set, the documentation says
[...]
Except for 'error_reporting', WordPress will set this to 4983 if WP_DEBUG is defined as false.
[...]
So my settings into php.ini were correct and sufficient. I don't even need the php-fpm settings, when errors are redirected to stdout in the php.ini file.
How to prevent WordPress from manipulating the error reporting?
This is not so easy, too. Although the WordPress documentation says, that the wp-config.php is a good place to set global wide settings like the error reporting, they got overwritten later to 4983. I don't know where; maybe it's not even the Core of Wordpress, but rather some poor developed plugin or theme.
We can handle this by adding error_reporting to the disabled functions:
disable_functions = error_reporting
Now it's not possible to overwrite our error_reporting. I think this is the best solution to make sure that we don't get any other error reporting by external influence from plugins or themes. Also in the future, since PHP allows such chaos, we need to reckon with such things.
Basically, we could criticize that this prevent us from getting more logs by setting WP_DEBUG to true, that's right, but as we're on a production system, it seems wrong for me to do troubleshooting in such a way there. We shouldn't do this on an application base, especially without display_errors! Instead, the workflow to find problems should be to look at the error logs.
Fatal errors should always be logged and checked on a regular basis. If that is not enough, error_reporting could be set on a higher level to get information about possible problems like warnings.
What is the most convenient way of error reporting in finished website? I would like to still log exceptions and errors to external file. I definitely don't want the user to see anything more than "Error: something went wrong, we are lookin into it".
Does my try - catch work and can I log my Exceptions if I set:
error_reporting(0);
In your php.ini file you should hide errors:
display_errors = Off
If you want to know about any errors that occur (you should care) you should turn on error logging:
log_errors = On
How to set error reporting depends on what errors you want to know about. Ideally you should want to know about everything (maybe except errors about deprecated stuff; if the website is already done then you should have fixed any such errors). See this page for more information.
; Show everything except deprecated errors
error_reporting = E_ALL & ~E_DEPRECATED
And then there are a few more things you can set:
; It makes little sense to have this on
html_errors = Off
; Set this to where your log file should be stored
error_log = /path/to/log/file.log
; Maybe more, see link below...
You can see some more options here.
Restart your server after making changes to php.ini.
I don't get any PHP error, just get a white page on Firefox, and
Server error
The website encountered an error while retrieving http://example.com/pruebas/prov.php. It may be down for maintenance or configured incorrectly
on Chrome.
This is the code:
if (!ini_get('display_errors')) {
ini_set('display_errors', 1);
}
echo "hola"
echo "hola2";
I intentionally made mistake in the echo "hola" (there's no ';').
I also tried adding to the end of my .htaccess file -> suPHP_ConfigPath /home/username/public_html replacing username with my current username, and then I created a php.ini in public_html with "display_errors = on;". But I'm still not able to get any PHP error.
Your script is dying due to the syntax error before it ever executes, so the ini_set() call is never executed and never takes effect. You'd have to change the setting in the appropriate php.ini.
The actual error message may be in a log file somewhere. Try Apache's error_log, or see if PHP's logging somewhere else.
Make sure that you also have the appropriate error_reporting ini value set as well. You can find more information on PHP.net
Set the error reporting level. The parameter is either an integer representing a bit field, or named constants. The error_reporting levels and constants are described in Predefined Constants, and in php.ini. To set at runtime, use the error_reporting() function. See also the display_errors directive.
In PHP 4 and PHP 5 the default value is E_ALL & ~E_NOTICE. This setting does not show E_NOTICE level errors. You may want to show them during development.
Source
Make sure the display_errors is set to on on your php.ini file.
Here is my code:
echo 'foo';
error_reporting(E_ALL);
echo 'this line doesnt end in a semi colon'
echo 'i should get an error here';
When I run this I get no error.
Not sure how this can be?
ini_set('display_errors', 1);
Do note though that if you do this in the file that has the syntax error, it won't work, as it'll never get executed then. You can also set this true in php.ini (not recommended for production servers), or if you use Apache, in .htaccess with:
php_flag display_errors 1
error_reporting directive won't help you to show error messages on-screen. It's responsible for which error to show, not where.
if your PHP runs as Apache module (most likely it does) add the following line into .htaccess file:
php_value display_errors 1
when you switch to production, change it to
php_value display_errors 0
php_value log_errors 1
and watch them it in the error log.
Do you have any kind of shutdown hooks, error-handling functions or global exception catchers running?
Syntax errors can be quirky in large frameworks :)
I have my site live in which i echoed few strings for testing, so it displayed me those test strings but along with the warning message
Warning: Cannot modify header
information - headers already sent by
(output started at
/home/companyfolder/public_html/mycart.php:117)
in
/home/companyfolder/public_html/includes/functions/general.php
on line 50
But at the same time i do not get this error any where in my local machine so i want to know is there any difference in display of header information related to servers?
Because of output buffering
And not a single one, who volunteered to share their knowledge about error handling, mentioned a way more likely reason - display_errors turned off, as it on the live site ought to be.
Of course it should be. To
not to scare users with strange messages
not to reveal vital info of your application to possible attacker. nor to supply them with any feedback.
inform a programmer of all errors occurred, by turning log_errors setting on
Thus, on a development site
display_errors = on
log_errors = off
on a live site
display_errors = off
log_errors = on
while error reporting level should remain the same - E_ALL or better
You have the same issue in both places, just different error reporting levels. You can configure this in your php.ini file or at runtime with error_reporting()
This error is pretty general, but basically what is happening is what it says. You're including mycart.php in a page and on like 117 it starts outputting HTML (or something client-side), once this starts happening you can't modify any of the header information (ex. a redirect). Like jason said though, the reason the error isn't showing up is the error_reporting setting.
EDIT: You can solve some of these problems by using ob_start() and then ob_end_flush() after you've done your header modifying.
Your other server configuration might have output buffering turned on in the php.ini file.
The server has this in php.ini
error_reporting(E_ALL);
if you just want errors then use
error_reporting(E_ERROR | E_PARSE);