php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #57660 Business Exceptions Data Returned to Client
Submitted: 2007-05-09 10:51 UTC Modified: 2007-06-29 09:02 UTC
From: michael dot caplan at henryschein dot com Assigned: mfp (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5.2.1 OS: CentOS 4
Private report: No CVE-ID: None
 [2007-05-09 10:51 UTC] michael dot caplan at henryschein dot com
Description:
------------
Reading through the docs, I understand that it is by design that business exceptions are relayed to the end user wholesale (IE: including backtrace, file, line, etc), and wrapped up in the binding native error structure.  For my purpose, I would like to relay exceptions to the end user, but I would like to suppress everything with the exception of the exception description and number.  Exposing files and backtraces in exceptions to the end user I think is too much info to expose (for security reasons, and simplicity).  

I don't see the value in having all this exposed to the end user, but I am sure there is a good reason.  Perhaps a setting could be put into place that would suppress all exception details except the message and code?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-15 13:09 UTC] mfp@php.net
You make a good point. I started a discussion thread on phpsoa. Let's see what ideas, if any, other people have.
 [2007-05-23 11:45 UTC] mfp@php.net
From the comments on the phpsoa thread, it looks as if the consensus is clearly to suppress the files and backtrace, as you suggest. Good suggestion.
 [2007-06-07 09:47 UTC] michael dot caplan at henryschein dot com
Hi Matthew,

As an implementation suggestion for the soap Wrapper binding, I did the following:

try {
    $return = call_user_func_array(array(&$this->instance_of_the_base_class,
    $method_name), $new_arguments_array);
} catch ( Exception $e ) {
    if ($e instanceof SoapFault) {
        throw $e;
    } else {
        throw new SoapFault('Client', $e->getMessage());
    }
}


I think this adequately re bundles the generic exception as a SoapFault, but also will just carry forward the exception as a SoapFault -- should it be formated as such. 

This allows me to have greater controller over Soap based exceptions, should I wish to return a specific SoapFault (with specific faultcode, faultstring, faultactor or details).  Since SoapFaults extend the core Exception class they could be handled easily in any other binding agnostically.
 [2007-06-11 12:46 UTC] mfp@php.net
Michael, thanks for suggesting a fix, I have applied it exactly as you proposed it.
 [2007-06-29 09:02 UTC] mfp@php.net
The patch you supplied wwent out in 1.2.2 (congratulations on being the first non-IBMer to make a fix to the core code!!!), so I am closing. Please feel free to reopen if you find the problem is still there.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Jan 25 01:03:34 2022 UTC