# SOAP SSL support doesn't work when allow_url_fopen is turned off - Thread: https://externals.io/message/17430 - Original archive: https://news-web.php.net/php.internals/17430 - Started by Wez Furlong on 2005-07-27T20:57:14+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #17430 — Wez Furlong — 2005-07-27T20:57:14+00:00 URL: https://externals.io/message/17430#17430 A bit of a WTF factor. The reason is doesn't work is because php_stream_locate_url_wrapper() respects allow_url_fopen(), and the soap code interprets failure as "SSL not enabled in this build" which is wrong. It it passed in the REPORT_ERRORS flag, the correct reason would be emitted or logged somewhere. There is currently no flag that can override the allow_url_fopen check in php_stream_locate_url_wrapper. The question is: should we bypass this check for SOAP? If not, we need to tweak the docs and have the soap extension report a more appropriate reason for failure. --Wez. --- ## #17431 — Sara Golemon — 2005-07-27T21:31:54+00:00 URL: https://externals.io/message/17430#17431 · In reply to: #17430 Two answers: (A) I do think an override is a good idea. There may be some cases where extension code may need to hook a wrapper whether allow_url_fopen is enabled or not. Granted the code could temporarily change that value, but that's a hackish approach. (B) I don't think SOAP is one of those cases. I would be dissapointed if SOAP allowed *any* calls to be made when allow_url_fopen is off. "Wez Furlong" wrote in message news:4e89b42605072713575d8f0d57@mail.gmail.com... A bit of a WTF factor. The reason is doesn't work is because php_stream_locate_url_wrapper() respects allow_url_fopen(), and the soap code interprets failure as "SSL not enabled in this build" which is wrong. It it passed in the REPORT_ERRORS flag, the correct reason would be emitted or logged somewhere. There is currently no flag that can override the allow_url_fopen check in php_stream_locate_url_wrapper. The question is: should we bypass this check for SOAP? If not, we need to tweak the docs and have the soap extension report a more appropriate reason for failure. --Wez. --- ## #17432 — Adam Maccabee Trachtenberg — 2005-07-27T22:45:20+00:00 URL: https://externals.io/message/17430#17432 · In reply to: #17431 > (B) I don't think SOAP is one of those cases. I would be dissapointed if > SOAP allowed *any* calls to be made when allow_url_fopen is off. I pretty much take it for granted that people are going to need to fetch the WSDL file from a remote location. Are you therefore saying SOAP support should be 100% diabled when allow_url_fopen is off? Do you apply the same limitations to, for example, cURL? Or am I misunderstanding you? -adam -- adam@trachtenberg.com | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! --- ## #17433 — Ilia Alshanetsky — 2005-07-27T22:50:05+00:00 URL: https://externals.io/message/17430#17433 · In reply to: #17432 Adam Maccabee Trachtenberg wrote: > I pretty much take it for granted that people are going to need to > fetch the WSDL file from a remote location. Not to mention do anything useful with it, like run queries :-) > Are you therefore saying SOAP support should be 100% diabled when > allow_url_fopen is off? SOAP is not disabled, simply prevented from querying remote data sources directly. > Do you apply the same limitations to, for > example, cURL? No, nor does it prevent `fsockopen()` or equivalent from being used to run queries. Ilia --- ## #17454 — Jason Sweat — 2005-07-28T16:04:32+00:00 URL: https://externals.io/message/17430#17454 > > […] > > Or constructs-that-look-like-functions could be governed by > disable_functions (eval, echo).. that would cause other problems (like a > disabled "return"), though. > > S I think Zeev's earlier comment about "If their aim is that good, they deserve to be shot in the foot" applies equally well to "disabled "return" " Regards, Jason --- ## #17466 — Paul Reinheimer — 2005-07-30T01:28:45+00:00 URL: https://externals.io/message/17430#17466 · In reply to: #17454 Since comments comments were called for I thought I might weigh in with my $0.02cdn When configuring PHP I want a way to protect myself, and my users from themselves when it comes to doing something silly, I've actually seen include($_GET['function']) in running code, though thankfully never on one of my projects. I would like to be able to prevent something like this from happening at the .ini level, wether thats allow_url_fopen or some other setting doesn't really matter. Beyond that, I'm only mildly interested in granularity, and then probably at the user/directory of execution level rather than the particular function level. So something like: allow_users_to_be_foolish(yes/no) -> disable remote file loading in include/require allow_remote_data_retreival(yes/no) -> disable remote file retreival with fopen, file_get_contents, streams, etc. If you're setting this option don't bother installing --with-curl, problem solved. Would suit me fine. Being able to do that in .htaccess or within some other apache based structure would be great, but not really needed. I agree with the previously mentioned "If their aim is that good, they deserve to be shot in the foot" completely paul > > > […] > > I think Zeev's earlier comment about "If their aim is that good, they > deserve to be shot in the foot" applies equally well to "disabled > "return" " > > Regards, > Jason > > -- > > > > -- Paul Reinheimer