SOAP SSL support doesn't work when allow_url_fopen is turned off

20 years ago by Wez Furlong — view source

unread

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.

20 years ago by Sara Golemon — view source

unread

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" kingwez@gmail.com wrote in message
news:4e89b42605072713575d8f0d57@mail.gmail.com...
A bit of a WTF factor.

--Wez.

20 years ago by Adam Maccabee Trachtenberg — view source

unread

(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!

20 years ago by Ilia Alshanetsky — view source

unread

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

20 years ago by Jason Sweat — view source

unread

That won't work, eval() is not a function...

Ah yes, you're right... I guess we do need another INI setting.

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

20 years ago by Paul Reinheimer — view source

unread

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

That won't work, eval() is not a function...

Ah yes, you're right... I guess we do need another INI setting.

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

--

--
Paul Reinheimer