我的主机上有一个神秘的 PHP SOAP 错误,但无法在本地复制

发布于 2024-07-12 00:30:51 字数 3105 浏览 9 评论 0原文

我遇到了一个有趣的 PHP/SOAP 错误,它让我陷入困境。 经过搜索,我没有找到合理的解释,非常感谢您的帮助。 背景如下:

我有一个用 PHP/CodeIgniter 构建的网站,它使用 SOAP 通过 SSL 与后端进行通信系统由第三方(我们称其为“X公司”以保护无辜者)提供,不在我的控制范围内。 本着良好的 MVC 精神,我将特定于与该数据源交互的代码放在单独的模型中 (system/application/models/company_x.php)。 我一直在 Mac 上使用 MAMP 进行本地开发,通过测试和开发几乎一切都相对顺利; 包括通过 SSL 调用 X 公司的 Web 服务。 我可能应该提到他们的 Web 服务有 PHP 5 的 SOAP 不喜欢的奇怪的 WSDL。 诸如所需参数之类的东西并不存在。 非常明确地调用 SOAP 方法有点奇怪,但我成功了,并且通过测试它起作用了。 我什至将其部署到 Mosso 的测试站点,我可以发誓它在一段时间内有效那里也有。

想象一下,当每次调用 SOAP Web 服务开始产生如下错误时,我会感到多么惊讶:

    A PHP Error was encountered
    Severity: Warning
    Message: SoapClient::__doRequest() [soapclient.--dorequest]: 
    WARNING: URL fopen access
    Filename: models/company_x.php
    Line Number: 86

错误日志除了服务器上模型文件的完整路径之外没有提供任何更多信息。 本地有效,之前我以为在Mosso也有效。 也许 Mosso 更改了他们的设置,并禁用了 SOAP 之类的东西。 稍后phpinfo(),他们就已经足够了。 我想也许我的Mac对SSL证书的容忍度更高。 毕竟,这是 GoDaddy *.domain.com 证书,也许 fopen 无法通过。 我制作了一个通过 SSL 连接的测试文件,并将其放在 Mosso 上,它成功了。

我想知道为什么 fopen 访问突然成为 SOAP 的问题? 莫索到底是什么原因让事情突然变得如此困难? 我需要覆盖某些 php.ini 设置吗? 难道像经常出现这样无益的错误一样,是完全不同的东西吗?

更新:这是 phpinfo() 的配置命令:

'./configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux -gnu''--target=x86_64-redhat-linux-gnu''--program-prefix=''--prefix=/usr''--exec-prefix=/usr''--bindir=/usr/ bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/信息''--cache-file=../config.cache''--with-libdir=lib64''--with-config-file-path=/etc'''--with-config-file-scan- dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl ' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '-- with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU ' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable- sysvmsg''--enable-track-vars''--enable-trans-sid'''--enable-yp''--enable-wddx''--with-kerberos''--enable-ucd-snmp- hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio ' '--with-ming' '--with-mime-magic' '--with-sqlite=shared' '--with-libxml-dir=/usr' '--with-xml' '--with-系统-tzdata''--with-apxs2=/usr/sbin/apxs'''--without-mysql'''--without-gd''--without-odbc''--disable-dom''--disable -dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--disable-json'

注意 :我在下面的评论是 phpinfo() 报告允许 Furl ; 诡异的!

I've run across an interesting PHP/SOAP error that has me stymied. After searching I have not found a plausible explanation, and I'd appreciate your help. Here's the background:

I have a site built in PHP/CodeIgniter which uses SOAP to communicate over SSL with a back-end system provided by a third party (let's call them "Company X" to protect the innocent) not in my control. In the spirit of good MVC, I put the code specific to interacting with that data source in a separate model (system/application/models/company_x.php). I have been developing locally using MAMP on my Mac, and just about everything was relatively smooth through testing and development; including calling Company X's web service over SSL. I should probably mention that their web service had strange WSDL that PHP 5's SOAP didn't like. Things like required parameters that were not there. It's been a little odd to call SOAP methods very explicitly, but I got it going and it worked through testing. I even deployed it to a test site at Mosso, and I could have sworn that it worked for a time up there too.

Imagine my surprise when every call to the SOAP web service starting producing errors like the following:

    A PHP Error was encountered
    Severity: Warning
    Message: SoapClient::__doRequest() [soapclient.--dorequest]: 
    WARNING: URL fopen access
    Filename: models/company_x.php
    Line Number: 86

The error logs didn't give any more information other than the full path to the model file on the server. It works locally, and I thought it worked on Mosso before. Maybe Mosso changed their settings, and disabled SOAP or something. A little phpinfo() later, and they have more than enough. I thought that maybe my Mac is more tolerant of the SSL certificate. After all, it's a GoDaddy *.domain.com cert, maybe fopen is having trouble getting through. I whipped up a test file to connect over SSL, and put it on Mosso and it worked.

I'm wondering why is fopen access suddenly a problem for SOAP? What is it about Mosso that is making this difficult suddenly? Do I need to override some php.ini setting? Could it be, like is so often with unhelpful errors like this, something completely different?

Update: here is the configure command from phpinfo():

'./configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-ming' '--with-mime-magic' '--with-sqlite=shared' '--with-libxml-dir=/usr' '--with-xml' '--with-system-tzdata' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--without-odbc' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--disable-json'

Note: My comment below that phpinfo() reports that furl is allowed; weird!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

云胡 2024-07-19 00:30:51

你可能有这个
http://us.php.net/ 缺少手册/en/filesystem.configuration.php#ini.allow-url-fopen

请记住,您始终可以使用 phpinfo() 直观地比较机器之间的环境。

You might have this
http://us.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen

missing.

Remember, you can always use phpinfo() to visually compare the environment between machines.

十六岁半 2024-07-19 00:30:51

另一种可能性(来自 PHP 文档):

注意:启用安全模式时,PHP 检查目录是否其中正在运行的脚本与正在执行的脚本具有相同的 UID(所有者)。

编辑:嗯..我在你的 PHP 编译选项中没有看到安全模式,所以可能不是这样。

Another possibility (from the PHP docs):

Note: When safe mode is enabled, PHP checks whether the directory in which the script is operating has the same UID (owner) as the script that is being executed.

EDIT: Hmm.. I don't see safe mode in your PHP compile options so it's probably not that.

夏尔 2024-07-19 00:30:51

好的,关于这个问题的一点更新:错误神秘地消失了,我没有做任何改变。 我不得不假设 Mosso 上存在一些奇怪的配置错误,并且已被悄悄修复。 X 公司的设置也极有可能存在问题。 在我看来,这是最糟糕的修复方式! 无论如何,感谢所有关注此事的人。

OK, a little update on this problem: the error mysteriously disappeared without any change from me. I will have to assume that there was some odd configuration error on Mosso that was silently fixed. It is also remotely possible that there was a problem with Company X's setup. That is the worst kind of fix IMO! Thanks anyway to everyone who looked in on this.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文