Phpxmlrpc Versions Save

A php library for building xmlrpc clients and servers

4.10.3

2 weeks ago
  • fixed: avoid emitting warnings when parsing some classes of malformed XML (issue #116)

  • fixed: the library will now return a Fault Response object with error code 2 whenever parsing some xml responses which do not conform to the specification, namely those having both fault and params elements inside methodResponse

4.10.2

3 weeks ago
  • fixed: allow Server subclasses to use their own Parser to determine the Request's charset

  • fixed: the Server would not swallow and log php warnings generated from end user's method handler functions unless debug mode was set to 2 or higher. It now does that always.

  • fixed: the library will now return a Fault Response object whenever parsing some xml responses which do not conform to the specification, namely the for following cases:

    • a methodResponse element without either fault or params
    • a methodResponse element with a params child which does not have a single param
  • improved: test on php 8.3

4.10.1

1 year ago
  • fixed: class autoloading got broken in rel 4.10.0 for users of the legacy API (issue #111)

  • fixed: let the Server create Response objects whose class can be overridden by subclasses (this is required by the json-rpc server now that the xml_header method has been moved to the Request object)

  • fixed: let the Client create Requests whose class can be overridden by subclasses, within the _try_multicall method, which is called from multicall

  • fixed: declare the library not to be compatible with old versions of 'phpxmlrpc/extras' and 'phpxmlrpc/jsonrpc'

4.10.0

1 year ago
  • changed: the minimum php version required has been increased to 5.4

  • changed: dropped support for parsing cookie headers which follow the obsolete Cookie2 specification

  • new: it is now possible to make the library generate warning messages whenever a deprecated feature is used, such as calling deprecated methods, using deprecated method parameters, or reading/writing deprecated object properties. This is disabled by default, and can be enabled by setting PhpXmlRpc\PhpXmlRpc::xmlrpc_silence_deprecations = false. Note that the deprecation warnings will be by default added to the php error log, and not be displayed on screen. If you prefer them to be handled in some other way, you should take over the Logger, as described below here

  • new: allow to specify other charsets than the canonical three (UTF-8, ISO-8859-1, ASCII), when mbstring is available, both for outgoing and incoming data (issue #42).

    For outgoing data, this can be set in $client->request_charset_encoding and $server->response_charset_encoding. The library will then transcode the data fed to it by the application into the desired charset when serializing it for transmission.

    For incoming data, this can be set using PhpXmlRpc::$internal_encoding. The library will then transcode the data received from 3rd parties into the desired charset when handling it back to the application.

    An example of using this feature has been added to demo file windowscharset.php

  • new: allow the library to pass to the application DateTime objects instead of string for all received dateTime.iso8601 xml-rpc values. This includes both client-side, for data within the $response->value(), and server-side, for data passed to xml-rpc method handlers, and works for both 'xmlrpcvals' and 'phpvals' modes. In order to enable this, you should set PhpXmlRpc\PhpXmlRpc::$xmlrpc_return_datetimes = true.

    NB: since the xml-rpc spec mandates that no Timezone is used on the wire for dateTime values, the DateTime objects created by the library will be set to the default php timezone, set using the 'date.timezone' ini setting.

    NB: if the received strings are not parseable as dates, NULL will be returned instead of an object, but that can be avoided by setting PhpXmlRpc\PhpXmlRpc::$xmlrpc_reject_invalid_values = true, see below.

  • improved: be more strict in the Response constructor and in Request::addParam: both of those will now generate an error message in the log if passed unexpected values

  • improved: be more strict in the data accepted as valid for dateTime xml-rpc values. Clearly invalid dates such as a month '13', day '32' or hour '25' will cause an error message to be logged or the value to be rejected, depending on configuration

  • improved: be more strict in the data accepted as valid for 'float' and 'int' xml-rpc values. If you need to allow different formats for numbers, you can set a custom value to PhpXmlRpc\PhpXmlRpc::$xmlrpc_double_format and PhpXmlRpc\PhpXmlRpc::$xmlrpc_int_format

  • new: allow the library to be stricter in parsing the received xml: by setting PhpXmlRpc\PhpXmlRpc::$xmlrpc_reject_invalid_values = true, incoming xml which has data not conforming to the expected format for value elements of type date, int, float, double, base64 and methodname will be rejected instead of passed on to the application. The same will apply for elements of type struct-member which miss either the name or the value

  • new: it is now possible to tell the library to allow non-standard formats for received datetime value, such as f.e. datetimes with a timezone specifier, by setting a custom value to PhpXmlRpc\PhpXmlRpc::$xmlrpc_datetime_format (issue #46).

  • new: it is now possible to tell the library to allow non-standard formats for received int and float values, as well as for methdoname elements. See the api docs for PhpXmlRpc\PhpXmlRpc static variables.

  • fixed: when a server is configured with its default value of 'xmlrpcvals' for $functions_parameters_type, and a method handler in the dispatch was defined with 'parameters_type' = 'phpvals', the handler would be passed a Request object instead of plain php values.

  • fixed: made sure all debug output goes through the logger at response parsing time (there was one printf call left)

  • fixed: Client::send will now return an error Response when it is requested to use an auth method that it does not support, instead of logging an error message and continuing with another auth schema. The returned error code is 20

  • fixed: when calling Client::multicall() with $client->return_type = 'xml', the code would be always falling back to non-multicall requests

  • fixed: support calling Client::setSSLVersion() for the case of not using curl transport

  • fixed: receiving integers which use the 'EX:I8' xml tag

  • fixed: setting/retrieving the php value from a Value object using array notation would fail if the object was created using i4 then accessed using int, eg: $v = new Value(1, 'i4'); $v[$v->scalrtyp()] = 2;

  • fixed: setting values to deprecated Response property cookies would trigger a PHP notice, ex: $response->_cookies['name'] = ['value' => 'something']; (introduced in 4.6.0)

  • fixed: made deprecated method Value::structEach work again with php 8.0 and later

  • new: method PhpXmlRpc::useInteropFaults() can be used to make the library change the error codes it generates to match the spec described at https://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

  • new: both Request and Response acquired methods getPayload and getContentType

  • new: method Response::valueType()

  • new: method Client::getUrl()

  • new: method Server::setDispatchMap()

  • new: added methods getOption, setOption, setOptions and getOptions to both Client and Server, meant to replace direct access to all public properties as well as the $timeout argument in calls to Client::send and Client::multicall

  • new: by using Client::setOption('extracurlopts'), it is possible to pass in protocol=specific options for when using the Socket http transport. The value has to be an array with key being 'socket' or 'ssl', and the value an array (see https://www.php.net/manual/en/context.socket.php and https://www.php.net/manual/en/context.ssl.php)

  • new: it is now possible to inject a custom logger into helper classes Charset, Http, XMLParser, inching a step closer to supporting DIC patterns (issue #78)

  • new: method PhpXmlRpc::setLogger(), to simplify injecting a custom logger into all classes of the library in one step

  • improved: the Client will automatically try to use cURL for requests using Digest/NTLM auth, unless told explicitly told not to do so via option 'use_curl'

  • improved: the Client is more verbose in logging issues when trying to compress a Request for sending

  • improved: the Logger class now sports methods adhering to Psr\Log\LoggerInterface

  • improved: limit the size of incoming data which will be used in error responses and logged error messages, making it slightly harder to carry out DOS attacks against the library

  • new: passing value -1 to $client->setDebug will avoid storing the full http response data in the returned Response object when executing call. This could be useful in reducing memory usage for big responses

  • new: when calling Wrapper::wrapXmlrpcMethod and wrapXmlrpcServer, it is possible to pass 'throw_on_fault' as option to argument $extraOptions. This will make the generated function throw on http errors and xml-rpc faults instead of returning a Response object

  • new: when calling Wrapper::wrapXmlrpcMethod, wrapXmlrpcServer, wrapPhpFunction and wrapPhpClass it is possible to pass 'encode_nulls' as option to argument $extraOptions. This will make the generated code emit a '' xml-rpc element for php null values, instead of emitting an empty-string xml-rpc element

  • new: methods Wrapper::holdObject() and Wrapper::getheldObject(), allowing flexibility in storing object instances for code-generation scenarios involving Wrapper::wrapPhpClass and Wrapper::wrapPhpFunction

  • improved: all Value methods now follow snakeCase convention

  • improved: all the Exceptions thrown by the library are now \PhpXmlRpc\Exception or subclasses thereof

  • improved: all the Client's setSomething() methods now return the client object, allowing for usage of fluent style calling. The same applies to Request::setDebug

  • improved: when calling Client::multicall(), the returned Response objects did not have any data in their httpResponse

  • new: method Helper\Date::iso8601Encode now accepts a DateTime input beside a timestamp

  • new: in the dispatch map, it is now possible to set different exception handling modes for each exposed xml-rpc method

  • new: method Server::add_to_map is deprecated in favour of addToMap. It has also acquired new parameters: $parametersType = false, $exceptionHandling = false

  • improved: the XMLParser accepts more options in its constructor (see phpdocs for details)

  • improved: removed usage of extension_loaded in favour of function_exists when checking for mbstring. This allows for mbstring functions to be polyfilled

  • improved: the code generated by the various code-generating methods of Wrapper are formatted better, and include more phpdoc blocks too

  • improved: made the Wrapper and Client classes easy to subclass for use by the PhpJsonRpc library

  • improved: added the library version number to the debugger title line

  • improved: the debugger will now sport the "load method synopsis" button when interacting with json-rpc servers

  • improved: added an example Symfony Client and Server to the demo files (using Symfony 6 / PHP 8 syntax)

  • improved: added to the taskfile command an option to automatically set up the git hooks for development

  • improved: made sure the test container and gha test runners have at least one locale with comma as decimal separator

  • BC notes:

    NB Given the considerable amount of API changes in this release, a set of tables listing every change has been added in doc/api_changes_v4.10.md; a textual description follows.

    Besides what can be inferred from the changes listed above, for library users:

    • the data passed to the application is not encoded anymore in UTF-8 when setting PhpXmlRpc::$internal_encoding to a custom character set and the mbstring extension is enabled. It will be encoded instead in the specified character set. We expect this to affect few users, as setting PhpXmlRpc::$internal_encoding to a custom character set did not make a lot of sense beforehand
    • the regular expression used to check if incoming int and double values are valid has been tightened. That can be tweaked via use of PhpXmlRpc\PhpXmlRpc::$xmlrpc_double_format and PhpXmlRpc\PhpXmlRpc::$xmlrpc_int_format
    • the regular expression used to check if incoming datetime values are valid has been tightened to reject clearly invalid dates. It has been widened as well, to allow leap seconds. That can be tweaked via use of PhpXmlRpc\PhpXmlRpc::$xmlrpc_datetime_format
    • a regular expression has been introduced to check incoming 'methodname' elements. In the default configuration it will trigger error messages in the logs, but not reject the calls. It can be tweaked via use of PhpXmlRpc\PhpXmlRpc::$xmlrpc_methodname_format
    • an error message will now be generated if, in incoming data, a STRUCT element has no NAME
    • parameters $timeout and $method are now considered deprecated in Client::send() and Client::multicall()
    • Client properties $errno and $errstring are now deprecated
    • direct access to all properties of Client and Server is now deprecated and should be replaced by calls to setOption / getOption. The same applies to the following "setter" methods of the Client: setSSLVerifyPeer, setSSLVerifyHost, setSSLVersion, setRequestCompression, setCurlOptions, setUseCurl, setUserAgent
    • direct access to Wrapper::$objHolder is now deprecated
    • the code generated by the debugger when using "Generate stub for method call" will throw on errors instead of returning a Response object

    For library extenders:

    • the $options argument passed to XMLParser::parse will now contain both options intended to be passed down to the php xml parser, and further options used to tweak the parsing results. If you have subclassed XMLParser and reimplemented the parse methods, or wholesale replaced it, you will have to adapt your code: both for that, and for making sure that it sets $this->current_parsing_options['xmlrpc_null_extension'] from PhpXmlRpc::$xmlrpc_null_extension
    • also, if you had reimplemented XMLParser::parse, be warned that:
      • you should return $this->_xh instead of void
      • the callers now treat differently results when _xh['isf'] > 3
    • Client protected methods sendPayloadSocket, sendPayloadCURL and prepareCurlHandle are now deprecated. They have been replaced by sendViaSocket, sendViaCURL and createCurlHandle respectively
    • if you subclassed the Client class, take care of new static variables $requestClass and $responseClass, which should be used to instantiate requests and responses
    • if you had been somehow interacting with private method Client::_try_multicall, be warned its returned data has changed: it now returns a Response for the cases in which it previously returned false, and an array of Response objects for the cases in which it previously returned a string
    • if you replaced the Logger class, take care that you will have to implement methods error, warning and debug (all is ok if you subclassed it)
    • calling method Value::serializeData is now deprecated
    • traits have been introduced for all classes dealing with Logger, XMLParser and CharsetEncoder; method setCharsetEncoder is now static
    • new methods in helper classes: Charset::knownCharsets, Http::parseAcceptHeader, XMLParser::truncateValueForLog
    • new method Response::xml_header has replaced Server::xml_header
    • protected property Server::$accepted_charset_encodings is now deprecated
    • exception \PhpXmlRpc\Exception\PhpXmlRpcException is deprecated. Use \PhpXmlRpc\Exception instead

4.9.5

1 year ago
  • improved: revised all demo files. Showcase more features in client demos; isolate better testsuite functions in server demos and make sure they are not active unless triggered by running the tests; add demos for code-generation for both clients and servers

  • improved: added cli command taskfile, which can be used to download the demo files or the visualeditor component for the debugger (requires bash, curl and a smattering of other common unix/linux/macos? tools)

  • improved: for php 7 and up, catch php Errors besides Exceptions thrown by method handler functions (ie. server-side)

  • fixed: when using the Exception or Error thrown by a method handler function to build the xml-rpc response, override fault Code 0, as it breaks response serialization

4.9.4

1 year ago
  • improved: updated the user's manual to be inline with the version4 API and modern coding practices. The manual is now bundled in the default distribution tarball, and is easily viewable as html, provided you can serve it using a webserver. It is also available as pdf at https://gggeek.github.io/phpxmlrpc/doc-4/phpxmlrpc_manual.pdf

  • improved: automated the process of creating the github release when pushing a release-tag to GitHub; also add a tarball of the demo files as release asset, and automatically update both http://gggeek.github.io and the code on altervista.org

  • improved: added a pre-push git hook script, to avoid pushing tagged versions with inconsistent version tags in code. To install it, execute composer run-script setup-git-hooks (NB: it is only useful for developers of this library, not for the developers simply using it)

  • fixed: the value for error 'no_http2' has been switched from 15 to 19 to avoid a collision

4.9.3

1 year ago
  • improved: avoid stalling the webserver when using the debugger with the php cli-webserver and testing the demo server within the same install

  • improved: allow installation of the jsxmlrpc library within the debugger folder via composer or npm to enable the visual-editing capabilities of the debugger, as this works well when the debugger is used as web-root (target usage scenario being f.e. using the php cli-webserver to run the debugger)

4.9.2

1 year ago
  • security fix: removed the possibility of an XSS attack in the debugger. Since the debugger is not designed to be exposed to end users but only to the developers using this library, and in the default configuration it is not exposed to requests from the web, the severity of this issue can be considered low.

  • improved: the debugger now uses jsxmlrpc lib version 0.6. It loads it from a cdn rather than locally. It also can make use of a 2nd constant to help telling it where the visual-editor form the jsxmlrpc lib is located, in case its path on disk relative to the debugger and its url relative to the web root do not match.

4.9.1

1 year ago
  • fixed: php warnings on php 8.2. This includes preferring usage of mbstring for converting between Latin1 and UTF8

  • improved: CI tests now also run on php 8.2

4.9.0

1 year ago
  • security fix: hardened the Client::send() method against misuse of the $method argument (issue #81). Abusing its value, it was possible to force the client to access local files or connect to undesired urls instead of the intended target server's url (the one used in the Client constructor).

    This weakness only affects installations where all the following conditions apply, at the same time:

    • the xmlrpc Client is used, ie. not xmlrpc servers
    • untrusted data (eg. data from remote users) is used as value for the $method argument of method Client::send(), in conjunction with conditions which trigger usage of curl as http transport (ie. either using the https, http11 or http2 protocols, or calling Client::setUseCurl() beforehand)
    • either have set the Clients return_type property to 'xml', or make the resulting Response's object httpResponse member, which is intended to be used for debugging purposes only, available to 3rd parties, eg. by displaying it to the end user or serializing it in some storage (note that the same data can also be accessed via magic property Response::raw_data, and in the Request's httpResponse member)

    This is most likely a very uncommon usage scenario, and as such the severity of this issue can be considered low.

    If it is not possible to upgrade to this release of the library at this time, a proactive security measure, to avoid the Client accessing any local file on the server which hosts it, is to add the following call to your code:

    $client->setCurlOptions([CURLOPT_PROTOCOLS, CURLPROTO_HTTPS|CURLPROTO_HTTP]);
    
  • security fix: hardened the Wrapper::buildClientWrapperCode method's code generation against code injection via usage of a malevolent $client argument (issue #80).

    In order for this weakness to be exploited, the following conditions have to apply, at the same time:

    • method Wrapper::buildClientWrapperCode, or any methods which depend on it, such as Wrapper::wrapXmlrpcServer, Wrapper::wrapXmlrpcMethod or Wrapper::buildWrapMethodSource must be in use. Note that they are not used by default in either the Client or Server classes provided by the library; the developer has to specifically make use of them in his/her own code
    • the $client argument to either of those methods should have been built with malicious data, ie. data controlled by a 3rd party, passed to its constructor call

    This is most likely an uncommon usage scenario, and as such the severity of this issue can be considered low.

    NB the graphical debugger which is shipped as part of the library is vulnerable to this, when used with the option "Generate stub for method call" selected. In that case, the debugger will display but not execute the malicious code, which would have to be provided via carefully crafted values for the "Address" and "Path" inputs.

    The attack scenario in this case is that a developer copies into his/her own source code the php snippet generated by the debugger, in a situation where the debugger is used with "Address"/"Path" input values supplied by a 3rd party. The malicious payload in the "Address"/"Path" input values should be easily recognized as suspicious by any barely proficient developer, as it resembles a bog-standard injection attack. It goes without saying that a responsible developer should not blindly copy and paste into his/her own code anything generated by a 3rd party tool, such as the phpxmlrpc debugger, without giving it at least a cursory scan.

  • fixed: a php warning on php 8 when parsing responses which do not have a Content-Type header (issue #104)

  • fixed: added a missing html-escaping call in demo file introspect.php

  • fixed: decoding of responses with latin-1 charset declared in the xml prolog but not in http headers, when on php 5.4, 5.5

  • fixed: DateTimeInterface is not present in php 5.4 (error introduced in ver. 4.8.1)

  • fixed: use of uninitialized var when accessing nonexisting member of legacy class xmlrpc_server - thanks SonarQube

  • new: the Client class now supports making calls which follow http redirections (issue #77). For that to work, use this code:

    $client->setUseCurl(\PhpXmlRpc\Client::USE_CURL_ALWAYS);
    $client->setCurlOptions([CURLOPT_FOLLOWLOCATION => true, CURLOPT_POSTREDIR => 3]);
    
  • new: allow users of the library to get more fine-grained information about errors in parsing received responses by overriding the integer value of PhpXmlRpc::$xmlrpcerr['invalid_xml'], PhpXmlRpc::$xmlrpcerr['xml_not_compliant'], PhpXmlRpc::$xmlrpcerr['xml_parsing_error'] and the equivalent PhpXmlRpc::$xmlrpcstr strings (feature req. #101)

  • improved: added the HTTP/2 protocol to the debugger

  • improved: CI tests now run on php versions 5.4 and 5.5, besides all more recent ones

  • improved: the test container for local testing now defaults to php 7.4 on ubuntu 20 focal