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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: michael dot caplan at henryschein dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2025 The PHP Group
All rights reserved.
Last updated: Tue May 13 10:01:27 2025 UTC