Hi all
I just noticed, that new class uses trigger_error. Should we use this function? We got security report about path disclosures and this introduces another way to disclose path information.
Marc Delisle schrieb:
Michal Čihař a écrit :
Hi all
I just noticed, that new class uses trigger_error. Should we use this function? We got security report about path disclosures and this introduces another way to disclose path information.
Yes, let's stay prudent on this.
Marc
But finding errors especially in classes/objects without this make it really hard sometimes!
If trigger_error() is a problem on a system than every error is a problem on this system.
If PMA would not give out any errors it just need to set his own error_handler.
I do not fully understand what is the problem with trigger_error or what makes the problems with trigger_error bigger than normal errors?
The real problem is displaying errors to the client, not triggering an error - so this is a system setting not an application setting.
The only way to handle this is that PMA uses his own error handler.
Or did i understand something completely wrong?
Hi
On Thursday 01 December 2005 09:05, Sebastian Mendel wrote:
But finding errors especially in classes/objects without this make it really hard sometimes!
Errors you added are mostly for user and not for developer. And user does not care where in class did error happen.
If trigger_error() is a problem on a system than every error is a problem on this system.
Yes, see PMASA-2005-2 [1]
If PMA would not give out any errors it just need to set his own error_handler.
I do not fully understand what is the problem with trigger_error or what makes the problems with trigger_error bigger than normal errors?
We should not issue any PHP errors nor warnings.
The real problem is displaying errors to the client, not triggering an error - so this is a system setting not an application setting.
The only way to handle this is that PMA uses his own error handler.
This might be a solution.
1. http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-2
Michal Čihař schrieb:
Hi
On Thursday 01 December 2005 09:05, Sebastian Mendel wrote:
But finding errors especially in classes/objects without this make it really hard sometimes!
Errors you added are mostly for user and not for developer. And user does not care where in class did error happen.
No, errors are for finding problems, whether by developer or admin (installer)
Really nice to have back this times with 'Exception Error' - this absolutely helpless error messages.
You have always to judge between security and user friendliness.
How can the developer help the user if the user can not provide a clear error message?
Hi
On Thursday 01 December 2005 11:56, Sebastian Mendel wrote:
No, errors are for finding problems, whether by developer or admin (installer)
Really nice to have back this times with 'Exception Error' - this absolutely helpless error messages.
I don't want nothing saying messages, I just want to avoid exposing information that should be hidden - path information in this case.
You have always to judge between security and user friendliness.
If we really need to make such choice, we need to choose security.
How can the developer help the user if the user can not provide a clear error message?
Showing strThemeNoValidImgPath (hey it's again not in language files) is IMHO good enough, you don't need to know that you raised this in line 107 of file Theme.class.php.
-
Marc Delisle -
Michal Čihař -
Sebastian Mendel