Fix #61094 Wrong WSDL cache file name

[joec4i]

WSDL cache files are created with the format wsdl-owner_username-uri_md5sum and with permission 0600. This has resulted in an error when two or more users are trying to run the same script that uses the same wsdl: only the first user can access to the wsdl cache file, while a second user will encounter a SOAP-ERROR complaining about not being able to load the WSDL. The bug was introduced in commit 1a9e668 which was supposed to use getuid() instead of php_get_current_user() in the cache filename.

To reproduce the problem, use the following code and run the script with two different users:

<?php
ini_set('soap.wsdl_cache_enabled', true);
$client = new SoapClient('http://www.webservicex.net/stockquote.asmx?WSDL');

The first user that runs the script should have no problem, but the second user (non-root) would see this error:

PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://www.webservicex.net/stockquote.asmx?WSDL' : failed to load external entity "http://www.webservicex.net/stockquote.asmx?WSDL"

Bug #51407 also describes the same problem.

Please take a look at it. Thanks.

[m6w6]

I'd rather see a patch where php_get_current_user, which is an oddment from safe_mode, is completely gone.

[joec4i]

It seems to me that implementing the windows version of getuid() would be overkill in an extension like soap, so instead I used the environment variable %USERNAME% for the cache filename generation. Please check it out. Thanks.

[Overtonesinger]

Amazing patch! I like it.

Just curious: the entity returned by the command:
char *user = getenv("USERNAME");

Does it behave like a smart pointer on Windows? I mean ... is it really garbage-collected automatically when the *user variable fades out of context?
I really do hope so.

[joec4i]

@Overtonesinger I thought this has been long forgotten lol.

According to https://stackoverflow.com/questions/4237812/should-i-free-delete-char-returned-by-getenv it should be safe. *user is a local variable so it should be destroyed at the end of function call.

[krakjoe]

@joec4i fix conflicts please :)

[krakjoe]

Having waited a month for feedback, and since there are merge conflicts, and unresolved doubts about the implementation, I'm closing this PR.

Please take this action as encouragement to open a clean PR against a supported branch, that deals with the doubts raised here.