On Thu, Jun 13, 2019 at 9:35 AM Lester Caine <les...@lsces.uk> wrote:

> Seen in the wild ... company name sanitised
>
> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
> /home/888/public_html/system/library/db/mysqli.php on line 7
>
> Fatal error: Uncaught exception 'Exception' with message 'Error: <br
> />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
> Stack trace: #0
> /home/888/public_html/system/nitro/core/nitro_db.php(29):
> DB\MySQLi->__construct('localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
> /home/888/public_html/system/nitro/core/nitro_db.php(13):
> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
> /home/888/public_html/system/storage/modification/system/library/db.php(11):
>
> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
> /home/888/public_html/system/framework.php(36):
> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
> require_once('/home/888 in
> /home/888/public_html/system/library/db/mysqli.php on line 10
> 你的代码出错了:
>
> I presume something has been updated that they have not been aware of
> since it's library file that triggered the warning ... but it's not the
> first time in recent years I've seen this sort of information on
> commercial sites and while my own clients just get white screens, those
> are created by the likes of Wordpress when 'automatic updates' happen.
>
> Many years ago the response was "well don't update", but 'current
> practice' takes that out of OUR hands! So isn't it time that the
> triggering exceptions like this did produce a more user secure response
> to protect against leaks like this and provide a better alternative than
> a white screen?
>
> In the case of this live site, I actually placed an order as it was only
> some links that triggered the fault, which may explain why they were not
> even aware there was a problem :( From the 'development' side, NitroDb->
> should obviously be handling the problem anyway.
>

display_errors=Off in production.

Nikita

Reply via email to