WebDAV and SOAP #

This page is for integrators who meet a requirement such as "editors save files from their desktop into the site" or "our middleware speaks SOAP". Exponential ships a WebDAV server (index_webdav.php) and a SOAP 1.1 server (index_soap.php). Both were called webdav.php and soap.php before 6.0.15; those names only forward now. Both are off by default, both have known gaps, and both are worth considering only when the other side cannot use something newer. Their status against the standards is in API and protocol standards.

Contents #

1. WebDAV
2. SOAP
3. Calling another system's SOAP service
4. When to use which

WebDAV #

Important: the entry script was renamed in 6.0.15 The WebDAV server is index_webdav.php (it was webdav.php until 6.0.14). webdav.php only forwards to it, writes a warning once a day, and will be removed in a later major version. Change your virtual host (HTTP and HTTPS) and rewrite rules, then test them: The WebDAV entry script is now index_webdav.php.

The entry point is index_webdav.php at the installation root. It runs the WebDAV server of the expcomponents, Exponential's fork of the Zeta Components (se7enxweb/expcomponents-webdav ~1.2.3) with the content backend kernel/private/classes/webdav/ezwebdavcontentbackend.php and basic authentication against Exponential users (ezwebdavcontentbackendauth.php).

Switch it on in settings/override/webdav.ini.append.php:

<?php /* #?ini charset="utf-8"?
[GeneralSettings]
EnableWebDAV=true
# the node WebDAV starts at (2 = the content root)
StartNode=2
# classes shown as folders
FolderClasses[]
FolderClasses[]=folder
*/ ?>

Permissions (since 6.0.15) #

What a WebDAV user may see and change is decided as on the web, in two steps:

Until 6.0.15 every read was granted before the policy check, and a refused PUT, MKCOL, DELETE, COPY or MOVE was answered with 201 or 204: the client showed a success and the change was lost. Check that WebDAV users have user/login for the siteaccess they use (/<siteaccess>/ in the WebDAV path), as they need for the web.

"Verify it's you" is never asked on WebDAV: it belongs to actions in the web interface. A second sign-in step is asked only where the site opts WebDAV in (Guard[]=webdav), see second sign-in step on other sign-in paths; an account without its ezuser_setting row cannot sign in.

SOAP #

The entry point is index_soap.php at the installation root; until 6.0.15 it was soap.php, which now only forwards to it and writes a notice to var/log/warning.log once a day (see the SOAP entry script is now index_soap.php). The library is lib/ezsoap/classes/ (eZSOAPServer, eZSOAPClient, envelope, codec, fault), SOAP 1.1 only, without WSDL. Switch it on and add the extensions that register functions, in settings/override/soap.ini.append.php:

<?php /* #?ini charset="utf-8"?
[GeneralSettings]
EnableSOAP=true
# enabled: the default siteaccess; disabled: matched from the request like any page
UseDefaultAccess=enabled

[ExtensionSettings]
SOAPExtensions[]=myintegration
*/ ?>

For each listed extension, index_soap.php includes extension/<extension>/soap/initialize.php, where the extension registers its functions with the server object $server (an eZSOAPServer). The syndication extension is the real example:

<?php
// extension/myintegration/soap/initialize.php
$server->registerFunction( 'myIntegrationStock', array( 'remoteID' => 'string' ) );

function myIntegrationStock( $remoteID )
{
    $object = eZContentObject::fetchByRemoteID( $remoteID );
    if ( !$object instanceof eZContentObject || !$object->canRead() )
        return 0;
    $dataMap = $object->dataMap();
    return isset( $dataMap['stock'] ) ? (int)$dataMap['stock']->toString() : 0;
}

When the request carries HTTP basic credentials, index_soap.php signs that user in before the call (eZUser::loginUser()), so the function runs with the user's policies. Without credentials it runs as anonymous. A second sign-in step never applies to SOAP: an account that needs one signs in with an app password (the second step on the other sign-in paths).

Letting it through the web server #

The shipped rewrite rules send every unknown address to index.php, so with SOAP on the web server must let index_soap.php through: uncomment RewriteRule ^index_soap\.php - [L] in .htaccess (from .htaccess_root), add RewriteRule ^/index_soap\.php - [L] to the HTTPS virtual host, or a location = /index_soap.php in nginx. Restrict it to the addresses of the systems that call it. Then check it:

curl -sS -i 'https://www.example.com/index_soap.php?wsdl'

The answer is 200 with "Error: this web page does only understand POST methods" (the server has no WSDL); a 404 or a page of the site means the rule is missing. The lines for Apache, Plesk, nginx, the other servers, a POST test with a SOAP envelope and the log check for clients still calling soap.php are on the SOAP entry script is now index_soap.php.

Calling another system's SOAP service #

eZSOAPClient sends SOAP 1.1 requests and verifies TLS certificates by default (tested in tests/tests/lib/ezsoap/eZSOAPClientTlsOptionsTest.php; see SOAP client TLS). For a modern SOAP service with WSDL, a SOAP 1.2 endpoint or WS-Security, PHP's own SoapClient (the soap PHP extension) is usually the better tool inside your extension.

When to use which #

Related pages #

• API and protocol standards
• SOAP client TLS
• The SOAP entry script is now index_soap.php
• Syndication between installations
• Integration surfaces at a glance
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.