I'm making a custom wrapper for the mysql_ functions when MySQLi, e.g. isn't available, and when it can't connect, it throws an exception. However, the fatal error output is this:
Fatal error: Uncaught exception 'Exception' with message 'Failed to
connect to database.' in C:\Program Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\MiniTicket\database.php:16Stack trace:#0
C:\Program Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\MiniTicket\database.php(49):
MySQL->__construct('localhost', 'miniticket', 'mtu:r!Nj#~qR6f9...')#1
C:\Program Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\MiniTicket\index.php(3):
require_once('C:\Program File...')#2 {main} thrown in C:\Program
Files (x86)\Apache Software
Foundation\Apache2.2\htdocs\MiniTicket\database.php on line 16
As you can see, my database password is clearly displayed for everyone to see. Not good. I don't want to turn these messages off, especially in development, but I don't want sensitive information displayed either. Using set_error_handler is also not a great solution, because I have to parse everything, and that's prone to error.
So... is there an easy way to disable the display of the parameters in a function inside an error message, preferably through PHP and not in some configuration file?
Edit: Disabling the filepath except for the filename would be a bonus, too.
You should separate your error handling between production and development where development displays the error information and production shows a friendly error message but does not output anything PHP does. Log the output to file instead.
Edit your php.ini and set
display_errors = 0
If you don't have access to php.ini then at the top of your script(s) you need to add:
ini_set("display_errors", "0");
See http://php.net/manual/en/errorfunc.configuration.php and http://php.net/manual/en/function.error-reporting.php
This will stop all errors from being outputted to the browser, and should probably only be done on your production system. Make sure you are still logging errors (via php.ini setting).
I'm not sure why this isn't the default configuration so that this situation doesn't happen in production environments.
Don't treat this as a solution to your software problem though, this is just meant to stop sensitive data from being displayed to the public.
Note that you may need to restart Apache for the php.ini changes to take effect.
Related
'''Fatal error: Uncaught Exception: Unable to open file /skins/MinervaNeue/skin.json: filemtime(): stat failed for /skins/MinervaNeue/skin.json'''
I tried running MediaWiki 1.38 (upgraded from 1.37.x) and tried using .git. Everything went smoothly, but after configuring the install through the browser (mw-config) I went to the site and got an 500 error. I turned on error reporting and got that error above (over and over). I’m on a shared hosting provider , I can’t edit the overall config, I can alter some php.ini settings, but I think it is something simple.
I tried changing my DB password in case it was that: Fatal Error Uncaught Exception unable to open INI file
I’ve already googled using different phrases and the exception with "php" and "mediawiki" Nothing except other fatal exception but none with failing to open a file. I’ve tried checking the permissions (directories are 755, and files are 774), checking the spelling of all the involved directories, changing the path to not use relative paths, re-downloading the skins, and changing which version of PHP (7.4 FastCGI to 7.4) I’m using from my ISP’s control panel. Nothing worked, and for a bit I broke it so bad that I was getting blank pages, but found those errors, But I can’t find the solution to this one. I’m out of Ideas. Help.
So, I it turns out the problem was my LocalSettings.php file was corrupted. Once I deleted the file (so it would cause mediaWiki to regenerated the file) & went into the mediaWiki setup again, and it worked as expected.
I run multiple WordPress sites which have multiple themes and plugins from multiple different authors. I always check my error log and try to contact the authors to fix bugs in their code, but a lot of them are logged as something like:
PHP Deprecated: wpmu_new_blog is <strong>deprecated</strong> since version 5.1.0! Use wp_insert_site instead. in /wp-includes/functions.php on line 5148
PHP Warning: array_merge(): Argument #3 is not an array in /wp-includes/class-wp-customize-widgets.php on line 376
PHP Warning: Error while sending QUERY packet. PID=23688 in /wp-includes/wp-db.php on line 2033
PHP Warning: mysqli_real_connect(): (HY000/2002): No such file or directory in /wp-includes/wp-db.php on line 1635
As you can see, the warnings occurred in files inside wp-include, which are available to all plugin/theme/core authors, so there is no way for me to find out who called the deprecated function, passed the wrong function parameters or whatever they did.
I also cannot easily reproduce the error in a dev environment because I don't know what action triggered it.
Everything would be much easier if I could change some PHP (or even server) setting that would cause a stack trace to be appended to each error log message.
This is one of those things that, as common as my problem probably is, Google is unhelpful because all search results try to explain how to append the stack trace to my own code, not to anyone's code.
You could install the Xdebug extension to PHP, which overrides the error logging mechanism of PHP and adds stack traces to errors, warnings, etc. when enabled. See Xdebug documentation.
I have recently set up XAMPP. The setup was straightforward but I don't seem to know the correct tweak to allow it to speak to the outside web world.
No matter how I try to read an external URL, it tells me where to get off.
(In PHP) I've tried the simple file_get_contents route. When that failed, somebody pointed me to curl. I enabled that in php.ini but that failed too.
I get the very unhelpful "Unable to open file"
Fatal error: Unable to open "https://earth.esa.int/documents/10174/1514862/Swarm_Level-2_TEC_Product_Description" in C:\xampp\htdocs\includes\PdfToText.phpclass:1665 Stack trace: #0 #2 {main} thrown in C:\xampp\htdocs\includes\PdfToText.phpclass on line 1665
I know this seems like an error with the class PdfToText (above) but it's just a way of showing the error. Take the file from between the quote marks, try to load it and it's fine. It doesn't want to open files from the outside world no matter what's tried.
I assume that it's a port/proxy/something but I've Googled all day in and out of stackoverflow and I cannot see the same problem anywhere.
Quick fix:
Find your php.ini file:
php -i | grep "Loaded Configuration File"
look for allow_url_fopen and set it to On
allow_url_fopen = On
Explanation:
This error happens because when you use functions like file_get_contents or fopen, you are handling file pointers, what allow_url_fopen will let you do is, resolve the url, create a tcp connection and create a network file pointer to that tcp connection, which will be handled by php as it were a file.
For security reasons, this setting is disabled on some installations.
Check the docs:
http://php.net/manual/en/filesystem.configuration.php
Having the same problem while installing the latest Prestashop on my server. So as #Agnes Tom has recommended, I changed the define.inc.php file and this is the error it´s showing up:
Warning: session_start(): open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2)
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/install/classes/session.php on line 47 Notice: Use of undefined constant _NEW_COOKIE_KEY_ - assumed '_NEW_COOKIE_KEY_'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/Cookie.php on line 79 Fatal error: Uncaught exception 'Defuse\Crypto\Exception\BadFormatException' with message 'Encoding::hexToBin() input is not a hex string.'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php:65 Stack trace:
#0 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php(164): Defuse\Crypto\Encoding::hexToBin('_NEW_COOKIE_KEY...')
#1 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Key.php(38): Defuse\Crypto\Encoding::loadBytesFromChecksummedAsciiSafeString('\xDE\xF0\x00\x00', '_NEW_COOKIE_KEY...')
#2 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(112): Defuse\Crypto\Key::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#3 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(46): PhpEncryptionEngineCore::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#4 /hermes/bosnaweb14a/b1 in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php on line 65
Warning: Unknown: open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
Warning: Unknown: Failed to write session data (files).
Please verify that the current setting of session.save_path is correct (/var/php_sessions) in Unknown on line 0
Might anyone helping me to know how to solve this error??
Thank you for your time
It's throwing an error saying it can't find or write to '/var/php_sessions/'
Do you have full access to the server?
If so, check if that folder exists and if the user or web server has permission to write to it, or change in php.ini
session.save_path = "/var/php_sessions"
To something like :
session.save_path = "/home/user/sessions"
Again, must be an existing folder with read/write permissions for the user or web server (this depends if you run the web server as own user or as account user).
If it's a shared envoirement, you better contact you hosting provider. Some allow you to have a php.ini in your hosting root and you could use it to change the session.save_path, others ignore it.
How to recognize the Error 500
First, we need to go over the different ways you might see this error message on your computer. There are different forms of this message because each host/server is allowed to customize the way it’s displayed. Here are some common ways you might see this error.
“500 Internal Server Error”
“HTTP 500 – Internal Server Error”
“Internal Server Error”
“HTTP 500 Internal Error”
“500 Error”
“HTTP Error 500″
Most times you will see this message accompanied by various forms of this classic ambiguous line
“The server encountered an unexpected condition that prevented it from fulfilling the request by the client”
It’s important to note that this error can be shown on any browser and any operating system (sorry, but switching to the new Mac Pro will not solve this problem) Here is a screenshot of one of the ways this error might be displayed on your browser.
Internal error server
What is the 500 Error?
Put simply, the 500 error is the Web servers way of saying “Something went wrong but I can’t tell you what, sorry.” This is what we call a “server-side” error. That means that there is something wrong with the server who is hosting the website. It is an extremely general error usually caused by configuration issues with the websites programming, PHP or system permissions.
How Can I Troubleshoot?
Don’t fret; although this error message is absurdly vague, you still have ways to find more information. Web servers are almost always configured to hide specific error messages. If your PrestaShop store is suffering from this debilitating error, you can turn on PrestaShop’s Error Reporting from FTP or your hosting’s CPanel to get more details.
There are two ways to turn on Error Reporting in PrestaShop depending on what version you have.
For PrestaShop v1.4 through v1.5.2
Open config/config.inc.php
On or around line 29 you will find this line
#ini_set('display_errors', 'off');
Change that line to read
#ini_set('display_errors', 'on');
For PrestaShop v1.5.3+
Open config/defines.inc.php
On or around line 28 you will find this line
define('_PS_MODE_DEV_', false);
Change that line to read
define('_PS_MODE_DEV_', true);
Once you enable error reporting through your FTP or CPanel, you can navigate back to your PrestaShop’s front or back office and reproduce the error or issue you are having. For example, if you are not able to access your website because of the 500 error, you will need to turn on error reporting and refresh the page(s) that had the error. There will be additional information that you can use to investigate the problem.
Investigating the Error
Once you have the additional information, there are some standard ways to further investigate the error. First, let’s go over some the most common ways this problem is caused. Once we find the cause of this error, it is much easier to solve.
Permissions: Many times you will find that the permission setting on one of your folders is set incorrectly. It could be a simple fix as switching a file/folder permission from 777 to 755 or vice versa. In most cases permission sets of 777 are extremely unsafe and can allow even an amateur hacker to access your files and put malicious code in it. Make sure to check with your hosting provider for specific information about permissions set as some servers have different regulations.
Incorrectly configured .htaccess: Oftentimes you will receive an internal server error when the htaccess file is configured incorrectly. For PrestaShop purposes, the main culprits of the htaccess errors are “URL Rewrite” settings or Friendly URL enabling. The htaccess syntax is very strict so even one wrong character or command will cause the server to return an Internal Error 500. Make a backup of your htaccess and regenerate the htaccess file either through the back office or by toggling the Enable Friendly URL option.
Server timeout: Every server has their own timeout setting, which sets the time that any given script can run. If the function or script crosses that limit, you will receive an error 500. The most common scripts in PrestaShop that can take too long to load are CSV Imports, backups, translation loading, import/exports and thumbnail regeneration. Many times the server limit is 30 seconds, which is not long enough to run these scripts. You should contact your hosting provider and inquire about changing the limit, at least temporarily.
Now, if the problem is not solved by investigating these common causes, you should also take a look at the Apache and PHP Error logs. These are provided by your hosting provider but sometimes you will need to contact them directly in order to have access to these log files.
When I say require("http://url.com/directory/file.php?test=name") it returns 0 why is this? I also cannot call values ($value) with PHP. How can I do this? What am I doing wrong here?
Turn up error reporting
error_reporting(E_ALL); to get the specific error message. If it is something like:
Warning: require() [function.require]:
http:// wrapper is disabled in the server configuration by allow_url_include=0
then you know that it is a security setting in php.ini
Although, I would imagine that you are actually retrieving the file, but its contents are '0'. I am guessing this because require will output 1 on success and throw a fatal error otherwise.
And as far as I know there is no values function in PHP.
Depending on your configuration you may not be able to include sources outside your host machine because it is a security vulnerability. It would be better to use curl to get the content from the secondary source.