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
On Thu, 13 Jun 2019 at 14:46, Lester Caine 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
On Thu, Jun 13, 2019 at 9:36 AM Marco Pivetta 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.
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
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 ...
As literally explained in the PR - dsns are already hidden from userspace.
See https://github.com/php/php-src/pull/2684#issuecomment-32567
Cheers, Sjon
On Thu, Jun 13, 2019 at 3:36 PM Marco Pivetta wrote:
> On Thu, Jun 13, 2019 at 3:30 PM Sjon Hortensius
> wrote:
>
>> FWIW - hiding databas
On Thu, Jun 13, 2019 at 3:30 PM Sjon Hortensius 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
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 wrote:
> Hey All
>
> Am 13.06.19 um 09:41 schrieb Nikita Popov:
> > On Thu, Jun 13, 2019 at 9:35 AM Lester C
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 materia
Hi,
On Thu, Jun 13, 2019 at 3:21 PM Lester Caine 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? Gi
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
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 stack
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 wrote:
>
> On 13/06/2019 08:55, Andreas Heigl wrote:
> >> display_errors=Off in production.
>
> Which give a white sc
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 whet
On Thu, Jun 13, 2019, 10:36 Lester Caine 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
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 t
Hey All
Am 13.06.19 um 09:41 schrieb Nikita Popov:
> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine 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
>>
On Thu, Jun 13, 2019 at 9:35 AM Lester Caine 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 '
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: />Error No: ' in /home/888/public_html/system/library/
19 matches
Mail list logo