SOAP: Fix wrong path to WSDL depending on endpoint

[mjansenDatabay]

See: https://mantis.ilias.de/view.php?id=42320

If approved (please test this thoroughly, and even better, take this as a start and provide a more elaborate solution to the problem), this has to be picked to trunk as well.

[sKarki999]

Dear @mjansenDatabay,

Thank you for the PR. :)

I have tested this PR and in the log i can see still an error.
You are right, this can be taken as a start and a more robust working solution needs to be in place.

I have few questions:

1. Could you please explain why the additional filesystem checks are necessary instead of directly relying on ilUtil::_getHttpPath()?
   Are these extra checks intended to handle any specific scenarios?

2. Is there a particular reason for choosing the number 20 for iteration?
   If not, would it perhaps make sense to define this as a constant for better maintainability?

I think it will be better if i provide a new PR for this mantis id rather than making the changes in the current PR.
What do you think? Please let me know :)

Kind regards,
Sagun

[mjansenDatabay]

Hi @sKarki999,

thanks for your feedback. I applied som changes to the PR.

I have tested this PR and in the log i can see still an error.

Can you provide more details about what was happening?

Are these extra checks intended to handle any specific scenarios?

They are needed because the server.php script of the "WebServices" component is not located in the public folder of ILIAS like other ILIAS endpoints, but rather in the public/soap sub-directory. There might be other endpoints (provided by plugin or core components) which also do not reside directly under the public directory, so we need a general approach to solve the problem.

If not, would it perhaps make sense to define this as a constant for better maintainability?

You are right, if we solve the issue in ilSoapClient, we could use a constant. If we solve it by providing a new method in ilUtil (like I know suggested in the modified PR), we should not (since this static helper class is marked as "deprecated` and covers dozens of different purposes/domains/context).

---

The main problem, which I've referred to in different PRs and Mantis issues, is that there is a lack of an internal API which reliably exposes information regarding:

1. The HTTP URL pointing to the public folder of ILIAS, which also can be used in non-web contexts (like cron).
2. The HTTP URL pointing to the current script being executed.

When consumers call \ilUtil::_getHttpPath(), they currently expect to retrieve the URL pointing to the directory of the PHP script currently running (see: 2.). In 99.9% of all cases, this is the ILIAS public folder, but if the running script is not located in the public folder, consumers must not use this static method if they need the ILIAS public HTTP path.

Of course, the approach here is only a temporary solution (as I said, ilUtil is deprecated).

The question is: Where does such an API reside? In the HTTP component? In Init? In App? In Environent?

Since I personally do not have the answer to this (of course, I have an opinion) and cannot decide on this topic alone, I initially suggested to change ilSoapClient to solve the issue locally.

---

You can test the changes and differences of the two methods:

1. Use the PR-branch for your ILIAS 10 installation
2. Login to ILIAS
3. Create some PHP scripts in the ILIAS public directory and some deeply nested directory structures below it with the following PHP code:

<?php

declare(strict_types=1);

error_reporting(-1);
ini_set('display_errors', 1);

chdir(__DIR__);
$ilias_root_directory = '';
while (!is_file($ilias_root_directory . 'ilias.ini.php')) {
    $ilias_root_directory .= '../';
}
chdir($ilias_root_directory);

require_once './vendor/composer/vendor/autoload.php';

ilInitialisation::initILIAS();

echo ilUtil::_getHttpPath();
echo "<br>";
echo ilUtil::getPublicHttpPath();

Best regards,
Michael

[sKarki999]

Hi @mjansenDatabay ,

Thank you for detailed explanation :)

Initial log issue which i was mentioning which came from the 1st commit is:

ilObjectCopyGUI::copyContainer:941 ilContainer::cloneAllObject: Trying to call Soap client...
ilObjectCopyGUI::copyContainer:941 Calling soap clone method
ilContainer::create:1603 ilObject::create(), start
ilContainer::create:1603 ilObject::create(), finished, obj_id: 662, type: cat, title: Source - Copy (48)
ilContainer::putInTree:1620 ilObject::putInTree(), parent_ref: 91, ref_id: 252, obj_id: 662, type: cat, title: Source - Copy (48)
ilObject::cloneObject:410 ilAdvancedMDValues::_cloneValues: No advanced meta data found.
atlas10_wsrv.WARNING: ilSoapUtils::callNextNode:178 Soap init failed with message: SOAP-ERROR: Parsing WSDL: Couldn't load from 'http:/soap/server.php?wsdl' : failed to load external entity "http:/soap/server.php?wsdl"
atlas10_wsrv.ERROR: ilContainer::cloneAllObject:1089 Calling webservice failed with message: Call to a member function __call() on null

Additionally, i also agree with your initial suggestion of modifiying the ilSoapClient class would be the right choice.

From the first commit, the URL is malformed and i suspect the dirname() is over stripping the URL.
In this case, the rough idea could be to split the URL into its parts, adjust only the path segment, and then reconstruct the full URL. If the malformed URL issue can be fixed, then i believe we already have the solution and modification lives only in ilSoapClient class.
Do you think this makes sense? Please let me know :)

Kind regards,
Sagun

[sKarki999]

Hi @mjansenDatabay ,
I have drafted a PR. #11214
I would be glad if you could take a look and see if this makes any sense or need correction ?
Thank you once again :)