SOAP heavily broken in 19.4.17

[leissbua]

Preconditions (*)

1. 19.4.17

Steps to reproduce (*)

1. Do Login via https://www.domain.com/api/v2_soap WS-I Compliant YES or NO

Expected result (*)

Login Result given

Actual result (*)

WS-I Compliant YES

PHP Fatal error: Procedure 'loginParam' not present in /home/cloudpanel/htdocs/www.domain.com/releases/2022_08_10_4_10_06_branch_master_soapfix/lib/Zend/Soap/Server.php on line 889

WS-I Compliant NO

SOAP-ERROR: Parsing WSDL: Unexpected WSDL element in /home/cloudpanel/htdocs/www.domain.com/lib/Zend/Soap/Server.php on line 814

[ADDISON74]

Does it work in 19.4.16?

[leissbua]

Yes - we did a rollback to 19.4.16 on several live instances that failed to handle SOAP. I guess its related to several XML fixes/checks coming in in the recent 19.4.17. Need to do more research tomorrow, was a long day.

I guess the error was introduced with following commit:

#2242

[fballiano]

I'll test tomorrow morning and try to find out the problem.

[fballiano]

I did a quick test with postman on a vanilla v19 (actually the 1.9.4.x branch) and it worked normally:

I could get the login token as usual

[fballiano]

and it seems to be working also on the checkout of the 19.4.17 tagged release.

can't check any further at this specific moment.

[elidrissidev]

It seems I'm able to login properly using the latest tagged version installed with composer.

Do you call the SOAP API in any specific way that we're not aware of (like using some third party tool)?

[leissbua]

thanks for adressing my issue.

php --info | grep soap.wsdl_cache_dir

delete the wsdl cache file and the problem starts. Was a bitch in the live site, as the flush happened by script. I am trying to break it locally and report back. But maybe the problem can be reproduced on your side by flushing the tmp dir.

[elidrissidev]

I'm able to reproduce now but only with WS-I Compliance Mode enabled.

$client = new SoapClient('http://magento.localhost/api/v2_soap/?wsdl'); 
$client->login((object)array('username' => 'apiUser', 'apiKey' => 'apiKey')); 
// SoapFault with message 'Procedure 'loginParam' not present'

[elidrissidev]

Also the error doesn't seem to happen if I disable the wsdl cache from the admin panel.

[fballiano]

I don't even know how to enable WS-I compliance mode 😅

[leissbua]

diff --git a/app/code/core/Mage/Api/Model/Wsdl/Config/Base.php b/app/code/core/Mage/Api/Model/Wsdl/Config/Base.php
index b3d21401e6..a142f99e51 100755
--- a/app/code/core/Mage/Api/Model/Wsdl/Config/Base.php
+++ b/app/code/core/Mage/Api/Model/Wsdl/Config/Base.php
@@ -56,7 +56,7 @@ class Mage_Api_Model_Wsdl_Config_Base extends Varien_Simplexml_Config
         // set up default WSDL template variables
         $this->_wsdlVariables = new Varien_Object(
             array(
-                'name' => 'Magento',
+                'name' => 'OpenMage',
                 'url'  => Mage::helper('api')->getServiceUrl('*/*/*', array('_query' => $queryParams), true)
             )
         );
        

This is what is breaking Magento SOAP. Need to dive in deeper.

EDIT: The acutal fix is in the wsi.xml file, that thing above was just a circumvention due to my old soap payloads.

[elidrissidev]

@fballiano System -> Configuration -> Magento Core Api

[leissbua]

Problem was an introduced bad targetNamespace, quesion is, why {{var wsdl.name}} was not kept, because as far as i can see, the problem would not have arisen:

-<wsdl:definitions xmlns:typens="urn:{{var wsdl.name}}"
+<wsdl:definitions xmlns:typens="urn:OpenMage"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
              xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
              xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
-             name="{{var wsdl.name}}"
-             targetNamespace="urn:{{var wsdl.name}}">
+             name="OpenMage"
+             targetNamespace="OpenMage">

[elidrissidev]

The main reason this change was made is because we wanted to introduce a CI workflow to validate XML files syntax, and since {{var wsdl.name}} is not a valid namespace it would generate false positive errors. I did spend a good amount of time trying to find a way to suppress these errors because I wasn't sure if this many changes may introduce unexpected issues in the future, but I never tested with WS-I mode enabled. I guess you can never be too cautious.

[leissbua]

This (changing the wsdl) has a tremendous impact on current installations, as most ERP-Systems cache the wsdl on their side. Just saying.