Everything

php

The real world ...

php.internals

Lester Caine

7 years ago

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?

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

Nikita Popov

7 years ago

On Thu, Jun 13, 2019 at 9:35 AM Lester Caine <lester@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

Andreas Heigl

7 years ago

Hey All

Am 13.06.19 um 09:41 schrieb Nikita Popov:

> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine <lester@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.
>

While that makes absolute sense perhaps thinking whether there is a way
to mark password-parameters in core-functions and hide them in
Stack-traces might improve security as that would also hide
user-provided credentials in log-files.
That would not target userland methods/functions. Though having a
Core-Value-object for credentials might even allow *that*

Just my 0.02 €

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+

Lester Caine

7 years ago

On 13/06/2019 08:55, Andreas Heigl wrote:

>> display_errors=Off in production.

Which give a white screen ... fine for security but useless for people
using the site!

> While that makes absolute sense perhaps thinking whether there is a way
> to mark password-parameters in core-functions and hide them in
> Stack-traces might improve security as that would also hide
> user-provided credentials in log-files.
> That would not target userland methods/functions. Though having a
> Core-Value-object for credentials might even allow*that*

Sanitising things would be a nice to have especially where log files are
on 'cloud' storage, but the ability to give an end user some indication
that there is a problem WHILE display_errors=Off would be helpful? I
know the white screen problem has been discussed many time over the
years ...

Personally I STILL use display_errors=on and just make sure that
sensitive information is not displayed in the stack. Most of the time it
IS just the warnings one gets and clients can report them and see they
are cleared ... so some sort of middle ground between off and on would
be helpful?

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

Marco Pivetta

7 years ago

On Thu, Jun 13, 2019, 10:36 Lester Caine <lester@lsces.uk> wrote:

> On 13/06/2019 08:55, Andreas Heigl wrote:
> >> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>

Error logging is how this is to be approached.

Personally I STILL use display_errors=on and just make sure that

> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?
>

Logging, logging, logging.

Displaying traces just gives malicious third parties a tasty data
exfiltration endpoint.

Andreas Heigl

7 years ago

Hey Lester, hey All

Am 13.06.19 um 10:36 schrieb Lester Caine:

> On 13/06/2019 08:55, Andreas Heigl wrote:
>>> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow*that*
>
> Sanitising things would be a nice to have especially where log files are
> on 'cloud' storage, but the ability to give an end user some indication
> that there is a problem WHILE display_errors=Off would be helpful? I
> know the white screen problem has been discussed many time over the
> years ...
>
> Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?

If you're so keen on providing the user something to see without having
to use display_errors=on: Have you had a look at
https://php.net/register_shutdown_function ?

You can always use that to figure out whether there was a fatal error
and then display something nice to the user.

No leaked stacktrace, no leaked credentials, user is informed, everyone
is happy :-)

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+

BohwaZ/PHP

7 years ago

> If you're so keen on providing the user something to see without having
> to use display_errors=on: Have you had a look at
> https://php.net/register_shutdown_function ?
>
> You can always use that to figure out whether there was a fatal error
> and then display something nice to the user.
>
> No leaked stacktrace, no leaked credentials, user is informed, everyone
> is happy :-)

Yup everyone should do that.

I personally like Tracy from Nette which has a production mode that will
show a nice error page: https://tracy.nette.org/en/guide

Perhaps PHP should display a page like that instead of a blank page when
display_errors is on "Off" no?

I've seen newcomers to PHP getting quite disturbed by just getting a
blank page and nothing else.

Andrey Andreev

7 years ago

Hi,

I too am in favor of a mechanism to strip out sensitive data from
error messages. But Lester, man, you have it all backwards ...

On Thu, Jun 13, 2019 at 11:37 AM Lester Caine <lester@lsces.uk> wrote:

>
> On 13/06/2019 08:55, Andreas Heigl wrote:
> >> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>

People using the site are not there to debug it. Whether they see a
white screen or an unhandled error that was never meant for them to
see, it's still bad user experience and of no use to anybody.

> Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?
>

You have logs to see the errors; relying on your users to report the
actual error messages to you is the worst way to do it.

Cheers,
Andrey.

Lester Caine

7 years ago

On 13/06/2019 13:04, Andrey Andreev wrote:

> You have logs to see the errors; relying on your users to report the
> actual error messages to you is the worst way to do it.

How many website logs can you manage on a daily basis? Given the volume
of material in heavily used website. I am STILL trying to get long
established sites back to a state where that would be a practical
approach. Especially when adding material is first element on the to-do
list. I've several hours of such work to get cleared first and prompts
in that traffic is easier to manage than then working through several
machines worth of logs ...

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

Andrey Andreev

7 years ago

Hi,

On Thu, Jun 13, 2019 at 3:21 PM Lester Caine <lester@lsces.uk> wrote:

>
> On 13/06/2019 13:04, Andrey Andreev wrote:
> > You have logs to see the errors; relying on your users to report the
> > actual error messages to you is the worst way to do it.
>
> How many website logs can you manage on a daily basis? Given the volume
> of material in heavily used website. I am STILL trying to get long
> established sites back to a state where that would be a practical
> approach. Especially when adding material is first element on the to-do
> list. I've several hours of such work to get cleared first and prompts
> in that traffic is easier to manage than then working through several
> machines worth of logs ...
>

There's a lot to say about how one can be effective at monitoring
logs, but that's not what I meant.

What I meant is, all a user needs to report to you is that there was a
problem, and since you have logs you can lookup whatever it was
(possibly asking just for a timestamp and/or IP address to pinpoint
the visitor).

Cheers,
Andrey.

Lester Caine

7 years ago

On 13/06/2019 13:30, Andrey Andreev wrote:

> What I meant is, all a user needs to report to you is that there was a
> problem, and since you have logs you can lookup whatever it was
> (possibly asking just for a timestamp and/or IP address to pinpoint
> the visitor).

JUST had a report of a problem ...
Deprecated: Non-static method LibertyMime::storeMetaData() should not be
called statically

I need to investigate why it thinks it's non-static but the irritating
bit here is that "It's just a warning" yet the operation has not
completed properly. Had I HIDDEN the warning the client would just have
ploughed on but now I can divert to fix the faulty bits of data and sort
the problem! It will be some silly thing missed, but in 20+ years of
code that are still a lot of those and simply hiding something and
waiting until later to clear the problems created is never going to be
right :(

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

Rowan Collins

7 years ago

On Thu, 13 Jun 2019 at 14:46, Lester Caine <lester@lsces.uk> wrote:

> Had I HIDDEN the warning the client would just have
> ploughed on but now I can divert to fix the faulty bits of data and sort
> the problem! It will be some silly thing missed, but in 20+ years of
> code that are still a lot of those and simply hiding something and
> waiting until later to clear the problems created is never going to be
> right :(
>

Don't underestimate the ability of users to plough on in the face of the
most obvious errors (and then on another day stop dead given the tiniest
unexpected message).

In this case, you already did "wait until later" - you waited until the
client saw it, and had the time and inclination to mention it to you. There
are far better solutions out there, as others have mentioned, that make
sure *you* see the message in good time. Then you can call up the client
and say "don't use this screen I think it's corrupting the data", rather
than them calling you up after they've entered 1000 corrupted records.

A generic message on PHP's default 500 error in place of the notorious
white screen would probably be useful, but it should be limited to
something like:

> A system error has occurred.
> Please contact the site administrator.
> If you are the site administrator, please check your error logs for

details of the error.

Regards,

--
Rowan Collins
[IMSoP]

Lester Caine

7 years ago

On 13/06/2019 15:51, Rowan Collins wrote:

> In this case, you already did "wait until later" - you waited until the
> client saw it, and had the time and inclination to mention it to you. There
> are far better solutions out there, as others have mentioned, that make
> sure*you*  see the message in good time. Then you can call up the client
> and say "don't use this screen I think it's corrupting the data", rather
> than them calling you up after they've entered 1000 corrupted records.

Still can't establish why the 'deprecated' message resulted in the image
upload failing to complete. The message was down to a missing 'static'
on a function that was triggered by the image metadata combined with the
'auto-rotate' of that particular image. Actually the image did not want
to be rotated but that is another matter. Plug in the missing 'static'
and the image loads, rotates and thumbnails. But without the message it
was not obvious the load had not completed. As it happens the next batch
of images did not see the problem which is obviously why it had been
missed. I had to go back to the image that I'd already manually fixed
and reload it to see the problem for myself :( Can you ever guarantee
perfect coverage of testing?

Several other sites are using the same code so one might expect it to
have turned up sooner and this machine has been through 7.0 and is now
running 7.2 so in this case am I just being clobbered by not picking it
up when moving from PHP5? A lot of the original single use functions
have grown static versions over the years since the deprecation and I
suspect there may still be others that may need work :(

By the way the site I posted originally has been completely down since I
emailed them about it ... which is annoying as I want to chase the order
I placed Monday ...

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

BohwaZ/PHP

7 years ago

Le 13/06/2019 14:20, Lester Caine a écrit :

> On 13/06/2019 13:04, Andrey Andreev wrote:
>> You have logs to see the errors; relying on your users to report the
>> actual error messages to you is the worst way to do it.
>
> How many website logs can you manage on a daily basis? Given the
> volume of material in heavily used website. I am STILL trying to get
> long established sites back to a state where that would be a practical
> approach. Especially when adding material is first element on the
> to-do list. I've several hours of such work to get cleared first and
> prompts in that traffic is easier to manage than then working through
> several machines worth of logs ...

Have you considered using solutions like Sentry?
https://sentry.io/welcome/

It gets added to the error handler and will report errors to a server.
Quite handy.

Another solution is to use the shutdown and error handler to send an
email to you when there is an error:

https://stackoverflow.com/questions/277224/how-do-i-catch-a-php-fatal-error

We used that solution for quite some time, but it can quickly overload
your email server when you have millions of requests producing errors ;)

Sjon Hortensius

7 years ago

FWIW - hiding database passwords (when using PDO) would be possible when
https://github.com/php/php-src/pull/2684 gets included

Cheers,
Sjon

On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl <andreas@heigl.org> wrote:

Marco Pivetta

7 years ago

On Thu, Jun 13, 2019 at 3:30 PM Sjon Hortensius <sjon@hortensius.net> wrote:

> FWIW - hiding database passwords (when using PDO) would be possible when
> https://github.com/php/php-src/pull/2684 gets included
>
> Cheers,
> Sjon
>

You'd still see the DSN in the traces.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Sjon Hortensius

7 years ago

As literally explained in the PR - dsns are already hidden from userspace.
See https://github.com/php/php-src/pull/2684#issuecomment-322222567

Cheers, Sjon

On Thu, Jun 13, 2019 at 3:36 PM Marco Pivetta <ocramius@gmail.com> wrote:

Dustin Wheeler

7 years ago

On Thu, Jun 13, 2019 at 9:36 AM Marco Pivetta <ocramius@gmail.com> wrote:

>
> You'd still see the DSN in the traces.
>

My understanding is that if using pdo.dsn.mysql via INI, you wouldn't
see the username / password in traces. I only learned about this
configuration reading through Sjon's PR, but looks reasonable.

To the original issue Lester faces:

The crux of all this is "don't use exceptions to do customer support"!

Most, if not all, log aggregation software (Splunk, ELK-stack, etc.)
give you the ability to configure dashboards or reports to highlight
different levels of "fail-boat" in the environment. We do this in our
environment, which is very heterogeneous and uncontrolled; filled with
undergraduates, graduates, faculty, staff, other IT organizations and
everything in-between. Not only do I have to deal with *my* logs, but
I also have to help facilitate improvements to tenant applications. If
it were me, I would be looking to your system administrators to
improve the configuration and management of your application
monitoring. If you don't have any automated monitoring (Splunk or ELK
(free), Telegraf/InfluxDB, Nagios even), look into these things.
Configure these to solve this problem rather than having customers be
the "free" monitoring solution as a default.

If I tried to pitch to my team that we would just use our users as THE
monitoring solution, I'd not only get some strange looks, but also a
can of surströmming thrown in my face. As developers and system
administrators, we can do better by our users to prevent these types
of errors before they hit them. We can do this through improvements to
our software design life cycle (or, to keep it simple... write tests
and develop somewhere other than production). Ultimately, we're never
going to catch everything... but customers reporting literal
exceptions should be... exceptional :)

P.S. I fully understand the "real world" sentiment even if I perceive
a different reality than yours. In the "real world", people get set in
their ways and higher-ed is no better a place that I have found to
observe this. However, in my experience, even the saltiest of faculty
with their 50 year old "Fortran codes" are amenable to change if it
makes their lives easier. Applying some of these strategies *will*
improve quality of work-life and *will* improve your business. Having
customers report low-level exceptions / stack-traces cannot be "good
for business" and must lower confidence in the product.

Cheers,

--
Dustin Wheeler | Software Developer
NC State University
mdwheele@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

Andreas Heigl

7 years ago

Am 13.06.19 um 15:30 schrieb Sjon Hortensius:

> FWIW - hiding database passwords (when using PDO) would be possible when
> https://github.com/php/php-src/pull/2684 gets included

I was more thinking of a more general approach as PDO is not the only
place where passwords are transfered. So having a generic Password-VO
that could be used like a password-string for BC but would not show up
in stack-traces - or at least not the cleartext-password - might improve
the security aspect regardless of where the password will be used. Yes,
at one point the cleartext-password needs to be handed over to the VO
and before that it will appear in stack-traces.


I did a userland-implementation but it still requires to hand over the
cleartext-password to relevant functions in PHP and there the stacktrace
can again leak the password. So having such a functionality in the core
would improve things.

Cheers

Andreas

>
> Cheers,
> Sjon
>
> On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl <andreas@heigl.org> wrote:
>
>> Hey All
>>
>> Am 13.06.19 um 09:41 schrieb Nikita Popov:
>>> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine <lester@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.
>>>
>>
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow *that*
>>
>> Just my 0.02 €
>>
>> Cheers
>>
>> Andreas
>> --
>>                                                               ,,,
>>                                                              (o o)
>> +---------------------------------------------------------ooO-(_)-Ooo-+
>> | Andreas Heigl                                                       |
>> | mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
>> | http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
>> +---------------------------------------------------------------------+
>> | http://hei.gl/root-ca                                               |
>> +---------------------------------------------------------------------+
>>
>>
>

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca                                               |
+---------------------------------------------------------------------+