[phpxmlrpc] R: R: [xml-rpc] Fatal error: Cannot redeclare xmlrpc_decode
I've taken a look at the CVS code, and it looks fine (note: I've not tried to use it, though). I would prefer to have at least one function name that is availale for usage regardless wheter the EPI extension is loaded or not (so the wary coder can program against that and deploy anywhere). php_xmlrpc_encode / decode is a recommended candidate. If code bloat is not a problem you could simply strip the if around the definition of these functions. Bye Gaetano -Messaggio originale- Da: Miles Lott [mailto:[EMAIL PROTECTED] Inviato: lunedì 27 dicembre 2004 15:20 A: [EMAIL PROTECTED] Oggetto: Re: R: [xml-rpc] Fatal error: Cannot redeclare xmlrpc_decode There is now a workaround in CVS. Please test this prior to installing over your current version (save a copy). It was tested on my install. Gaetano Giunta wrote: The PHP-bundeled xmlrpc extension comes with a function named xmlrpc_dedode (as well as encode). The phpxmlrpc lib uses the same name for its functions. Either you: - disable the php xmlrpc extension (modify php.ini on windows, recompile on unix) - comment the relevanmt sections of xmlrpc.inc - rename the two functions in xmlrpc.inc to something else This bug is reported in the sourceforge project page, commented and dissected. Ciao gaetano ... ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
R: [phpxmlrpc] Arguments not passed through
weird indeed: I tried this:
$f=new xmlrpcmsg('auth', array(
new xmlrpcval(someUsername),
new xmlrpcval(somePassword)));
print out = . $f-serialize();
and got
out = ?xml version=1.0?
methodCall
methodNameauth/methodName
params
param
valuesomeUsername/value
/param
param
valuesomePassword/value
/param
/params
/methodCall
in the browser.
(of course, looking at the 'source view' of the page genrated by php. the xml
showed up as out = auth someUsername somePassword )
What version of PHP are you running?
Are you using the 1.0.99.2 version or the files from CVS?
By the way, are you testing the exact code you sent?
I ask because it looks like the decoding of the response from the xmlrpc server
works ok, and it is starnge that decoding works but encoding does not, so I
suspect the error could be in the username and password values not being set
before creation of the xmlrpcmsg object.
An option is to use the php xmlrpc server, with its debugging option turned on:
it will send back to the clients the complete request it received...
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] conto di
Niklas Saers
Inviato: martedì 1 febbraio 2005 14:46
A: phpxmlrpc@usefulinc.com
Oggetto: [phpxmlrpc] Arguments not passed through
Dear sirs,
I'm trying to do XMLRPC/SSL via PHP and I'm using your library that I
found on sourceforge. But apparently no variables are sent with the
request, or they are emptied. Can anyone tell me why they are sent as
empty strings? I'm using the latest published version of the
libraries.
Here is my code:
$f=new xmlrpcmsg('auth', array(
new xmlrpcval(someUsername),
new xmlrpcval(somePassword)));
print out = . $f-serialize();
// This outputs only
// out = auth $c=new
xmlrpc_client(/, $server, 1443);
$c-setSSLVerifyPeer(0); $c-setDebug(1);
$r=$c-send($f,20,https);
This outputs:
out = auth ---GOT---
HTTP/1.0 200 OK
Server: BaseHTTP/0.2 Python/2.2.2
Date: Tue, 01 Feb 2005 11:37:49 GMT
Content-type: text/xml
Content-length: 158
?xml version='1.0'?
methodResponse
params
param
valuestringERROR, invalid username/password/string/value
/param
/params
/methodResponse
---END---
HEADER: HTTP/1.0 200 OK
HEADER: Server: BaseHTTP/0.2 Python/2.2.2
HEADER: Date: Tue, 01 Feb 2005 11:37:49 GMT
HEADER: Content-type: text/xml
HEADER: Content-length: 158
---EVALING---[53 chars]---
new xmlrpcval(ERROR, invalid username/password, '');
---END---
And the debug messages from my server is:
username = and password =
The same stuff works excelent with both Python and Java. But
now I need
to do this with PHP. Any ideas?
Cheers
Nik
___
phpxmlrpc mailing list
phpxmlrpc@lists.usefulinc.com
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
___
phpxmlrpc mailing list
phpxmlrpc@lists.usefulinc.com
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
R: [phpxmlrpc] HTTP/1.1 100 Continue
What's happening (IMHO) is that the server is sending an invalid response: If you look at the spec for HTTP 1.0 (rfc 1945), which is the dialect that the xmlrpc client uses, you will see that responses 'HTTP 100' are NOT allowed. The client does not understand this response, and it probably never will, for two reasons: - the client does not even really undertsand fully HTTP 1.0, it only groks HTTP 200 OK responses, and no-one volunteerde (yet) to add more complete protocol support to it - it is the fault of the server anyway to send it back (see also rfc 2145 for http 1.1 / 1.0 interop: http 1.1 responses to 1.0 requests HAVE to be also valid http 1.0 responses...) so you can either: - modify server config: have the 'http 100' line removed - patch xmlrpcs.inc on your own to transparently drop the 'http 100' line - wait for the next version of the lib, maybe someone will add better http support (I'm planning to use CURL for http calls, so that that the client will get free http 1.1 support) Bye gaetano -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Wolfgang Pichler Inviato: mercoledì 2 febbraio 2005 15:13 A: phpxmlrpc@lists.usefulinc.com Oggetto: [phpxmlrpc] HTTP/1.1 100 Continue Hi, i am using your xmlrpc.inc (// $Id: xmlrpc.inc,v 1.20 2003/01/10 22:01:56 dilinger Exp $) php class. Its working perfectly - beside one thing: It can be that the http response looks like: --- HTTP/1.1 100 Continue HTTP/1.1 200 (OK) Date: Wed, 02 Feb 2005 11:45:09 GMT Server: Apache Content-Length: 277 Content-Type: text/xml ?xml version=1.0? here does come the rest of the xml document --- in this case it will fail - but thats a valid response So, what can i do to get this working ? regards, Wolfgang ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
[phpxmlrpc] New release of phpxmlrpc - fixes security vulnerability
Version 1.1.1 of the library has been released, with an important security fix. All users are inited to upgrade asap. http://sourceforge.net/projects/phpxmlrpc/ ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
RE: [phpxmlrpc] xmlrpc_encode_entitites causing parse error
OK, code checked in into CVS. Feel free to download and test it (I added a new test case for UTF-8 in testsuite, but the more testing the better). I adopted the 'convert all to ASCII' way-of-life, and modified the function xmlrpc_encode_entities() to respect the value of $GLOBALS['xmlrpc_internalencoding']. As stated in my last post, more flexible usage patterns might make it into future releases. Right now escaping iso-8859-1 might be faster than it was previously, since I use str_replace instead of the hand-made algorithm, but escaping UTF8 will be dog slow. The lib is not built for speed anyway, if you're aiming for that the php xmlrpc extension will surely server you better. The main problem I see with that right now are: - turning xmlrpc_encode_entities() into a general charset transcoder migth make it slower for the default case operation, unless user has mbstring ON - how server and msg objs will communicate to xmlrpcval objs the desired charset for serialization (only solution I can think of: add an extra param in calls to serialize()) - xmlrpc_encode_entities() is used when serializing server-added debug info. Since that info might come at the same time from user messages, client request (at debug lvl 3) and php error messages, there is a serious risk it will be a charset pot-pourri, ie there is no sure way that it will conform to ANY charset. I wonder if using a CDATA section instead of a comment to wrap debug info might help in solving this problem. The second solution is to just base64-encode the debug info, and let the client sort it out. Of course that would break any existing client that makes usage of that undocumented info... Bye Gaetano -Original Message- From: a.h.s. boy (lists) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 15, 2005 6:57 PM To: Gaetano Giunta Cc: phpxmlrpc@lists.usefulinc.com Subject: Re: [phpxmlrpc] xmlrpc_encode_entitites causing parse error On Nov 15, 2005, at 11:31 AM, Gaetano Giunta wrote: Very toughtful response. Man, I love cross-linguistic typos...makes great new English words: toughtful = tough thoughtfulness. Brilliant. UTF-8 everywhere is fine and dandy but for 2 aspects: - in fact XML-over-http without a charset declaration SHOULD be assumed to be ISO-8859-1 (there is a RFC somewhere about that, which I cannot recall now). Hmmm. The XML 1.0 spec (http://www.w3.org/TR/2000/REC-xml-20001006) reads: Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding MUST begin with an XML encoding declaration, in which the first characters must be '? xml', any conforming processor can detect, after two to four octets of input, which of the following cases apply. RFC 2376, however, offers suggestions for XML MIME-types sent over HTTP, but it reads (pardon the length): Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. UTF-8 [RFC-2279] is the recommended value, representing the UTF-8 charset. UTF-8 is supported by all conforming XML processors [REC-XML]. If the XML entity is transmitted via HTTP, which uses a MIME-like mechanism that is exempt from the restrictions on the text top- level type (see section 19.4.1 of HTTP 1.1 [RFC-2068]), UTF-16 (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) is also recommended. UTF-16 is supported by all conforming XML processors [REC-XML]. Since the handling of CR, LF and NUL for text types in most MIME applications would cause undesired transformations of individual octets in UTF-16 multi-octet characters, gateways from HTTP to these MIME applications MUST transform the XML entity from a text/xml; charset=utf-16 to application/xml; charset=utf-16. Conformant with [RFC-2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of us-ascii. In cases where the XML entity is transmitted via HTTP, the default charset value is still us-ascii. ...which implies that us-ascii, not iso-8859-1, is the default (but not really a problem if you're encoding everything outside of ASCII). But I know that my RDFParser class, for example, defaults to utf-8 and overrides that only if the encoding is specified as something else in the xml delaration. I assume I made that decision for good reasons, though I don't remember them now! Still, the number of factors affecting
RE: [phpxmlrpc] Multiple signatures
BTW: the method sig must be an array of arrays, wheter you have only one valid sig or more. If, in your code, $xrs = new xmlrpc_server(array( 'examples.myFunc' = array( 'function' = 'foo', 'signature' = array($mysig1array, $mysig2array) ) )); mysigarray1 and mysigarray2 are already both an array of array, I see how this could generate a warning. maybe you could try with: 'signature' = array($mysig1array[0], $mysig2array[0]) Bye Gaetano -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Tupholme Sent: Monday, February 13, 2006 7:27 PM To: phpxmlrpc@lists.usefulinc.com Subject: Fwd: [phpxmlrpc] Multiple signatures I see now that such notices are a known issue when running on PHP 5. However, it does suggest that multiple signature support is not perfect! I'll try again when PHPXMLRPC 2.0 is final. Thanks for your help. Jeff Begin forwarded message: From: Jeff Tupholme [EMAIL PROTECTED] Date: 10 February 2006 11:39:19pm GMT To: phpxmlrpc@lists.usefulinc.com phpxmlrpc@lists.usefulinc.com phpxmlrpc@lists.usefulinc.com Subject: Re: [phpxmlrpc] Multiple signatures Thanks for the help and sorry to be so long in replying! I've tried calling 'system.methodSignature' with the correct (second, below) form of my method declaration in place, and I get the following back: lt;br /gt; lt;bgt;Noticelt;/bgt;: Array to string conversion in lt;bgt;xmlrpc.inclt;/bgt; on line lt;bgt;507lt;/bgt;lt;br /gt; lt;br /gt; lt;bgt;Noticelt;/bgt;: Array to string conversion in lt;bgt;xmlrpc.inclt;/bgt; on line lt;bgt;511lt;/bgt;lt;br /gt; ... This of course breaks the response. The same happens if I add my method using add_to_map(). I appreciate I could suppress the error (via reporting levels) to make it work, but I'd rather fix the problem at source. Anyone seen this before, please? I don't see that I have any more arrays than I need! Thanks, Jeff On 31 Jan 2006, at 9:17am, Gaetano Giunta wrote: The first example is wrong, by virtue of php syntax: you are declaring twice the value of the 'signature' member of the array. The second declaration wins, and the only valid signature you get is $mysig2array. The second declaration looks ok to me. Are you sure that you are not mixing up the $mysig1array and $mysig2array arrays or omitting the return type as first value of $mysig1array and $mysig2array? Your best bet is to call a system.listmethods on your server, and see what it declares to expose. If you upgrade to version 2.0 of the lib, you will get for free a debugger (same interface as you get on http://gggeek.damacom.it/debugger ) that will do the job for you, and show results of the system.listmethods call in a nicely formatted table - very useful for introspection! Bye Gaetano Hi, I'm trying to create a method with multiple signatures and having problems. I've tried both the following formats (for illustration, I actually have four variants): $xrs = new xmlrpc_server(array( 'examples.myFunc' = array( 'function' = 'foo', 'signature' = $mysig1array, 'signature' = $mysig2array ) )); $xrs = new xmlrpc_server(array( 'examples.myFunc' = array( 'function' = 'foo', 'signature' = array($mysig1array, $mysig2array) ) )); I can confirm the signature arrays themselves are OK by using them one at a time. When I combine them in the first form I get an error similar to: Incorrect parameters passed to method: Wanted array, got string at param 2 ... as it seems to get the various signatures confused. The second form yields: Incorrect parameters passed to method: No method signature matches number of parameters I'm using PHPXMLRPC 1.2.1 with PHP 5.1.1. Thanks in anticipation of any helpful suggestions. ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
RE: [phpxmlrpc] User authentication
Authtentication and authorization are complex subjects, and there is no 'single solution' that fits all situations. To decide on the best setup for your needs you should start with the following questions: -will there be a single webservice consumer application or does the systemhavemultiple different users? - is there need for https, eg. do the webservices transfer sensitive data over public networks (internet)? - is there any need for integrating user authentication with pre-existing solutions (eg windows active directory / ldap)? 1) For the 'very simple case', e.g. one single webservice-consumer-application, that has full access to every web service, you can very quickly and easily use the authentication provided by your web server, be it either Apache or IIS (look at the appropriate documentation). If you need to give different access rights to different web services, you could put upmany server.php pages, each serving some xmlrpc method, and assign different access rights to those (in fact you could put the business logic used by the webservices in functions/classes in separate php scripts, and simply include the scripts with the business logic from within the php scripts that expose the web services. this makes for a very clean architecture). You need to make sure that the xmlrpc client you are using has support for the kind of HTTP authentication you are setting up. If you are using phpxmlrpc as web service consumer, the client has support for http Basic auth, and for https when CURL is enabled. With recent php and curl versions, you might also get support for NTLM authentication, but I never tried it out... Otoh you might 2) use php sessions for enabling authentication, or 3) use some home-brewed method that puts the authorization token inside the xmlrpc calls themselves. Both options can turn out to be quite complex in implementation in the real world, even though they offer greater flexibility over web-server authentication. If you use php sessions, you need to enable the session stuff in your server.php file, but must take care that it does not interfere too much with the http handling that is carried out by the library itself. The xmlrpc client must also support using cookies, which many libraries do not do. If you use the phpxmlrpc library as client, you should e.g. extract by hand the cookie from the first xmlrpc response received, and use itadding itby hand intosuccessive requests. If you use inside-the-webservice auth, the scheme would look something like this: - app calls webservice 1, passing crdentials. webserver validates credentials, generates token, saves it into local db/session storage, and send it to client as response - app receives token, and uses it as first (last?) parameter for every successive xmlrpc request - all webservices (except the authenticating one) on the server must check for the presence of a valid token as first parameter - you should add a close-seeion webservice for extra security, and take into account basicattacks suchas session-injection and fixation, incase you have to guarantee real security disclaimer: I am not a security consultant Bye Gaetano Giunta -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jem MawsonSent: Monday, March 27, 2006 3:38 AMTo: phpxmlrpc@lists.usefulinc.comSubject: [phpxmlrpc] User authenticationHelloI'm very new to PHP, taking it up primarily to use the XML-RPC package.I would like to protect most of my rpc methods such that they will only execute when called by an authorised user. I'm not quite sure how to go about authentication though. Does anybody have a best practices guide on how to achieve client authentication? Is it best to use http basic auth and check credentials on each method call? Or is there some inherent PHP support for sessions that can be used? Yours confusedly,Jem-- http://www.loftinspace.com.au/jem ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
RE: [phpxmlrpc] Sending XML Strings
Sorry about that, I'll update the docs. To achieve the desired effect, just use $client-send($thecompletexmlpayload) Just take care about charset encodings... Bye Gaetano -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Kist Sent: Thursday, May 11, 2006 3:11 PM To: phpxmlrpc@lists.usefulinc.com Subject: [phpxmlrpc] Sending XML Strings In the release notes for 2.0 RC 1, from end of 2005, it said that the send method would now be able to accept XML strings, but there is nothing documented about it.How can i use the send() method to send an XML string rather than an instance of an xmprpcmsg class? Thanks! -Kid A ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc ___ phpxmlrpc mailing list phpxmlrpc@lists.usefulinc.com http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
Re: [phpxmlrpc] Special special chars in XML Response
The answer was clearly given without enough thinking...
The first question is: are you using the lib to write the client, the
server or both?
Then some explanations:
- on line 922, if the server has received some CP1252 text, it should
default to $GLOBALS['xmlrpc_defencoding']='UTF-8'. Did you also change
that variable? otherwise I cannot explain it...
- are you using php 4 or 5? there are some differences between the xml
parser use by php
- there is some more work surely to be done for everything to work fine.
Setting internalencoding to CP1252 before emitting (encoding) data is
fine, but, as you have seen, it cannot be used when decoding it. And
both server and client decode data (request and response, respectively).
Since cp1252 is not supported by the php4 xml parser, we have to find
some workaround
Bye
Gaetano
Hi Gaetano,
thank you for your fast reply and advice! I implemented the steps as
you described, but when setting
$GLOBALS['xmlrpc_internalencoding']='CP1252'; I am now getting the
following error:
Warning: xml_parser_set_option() [function.xml-parser-set-option]:
Unsupported target encoding quot;CP1252quot; in
...\module_xmlrpc\lib\xmlrpcs.inc on line 922
The PHP documentation says the only support ISO-8859-1, US-ASCII and
UTF-8: http://de3.php.net/xml_parser_set_option
How can I further tackle this issue?
Thanks and best regards,
Matthias Korn
Gaetano Giunta schrieb:
The characters you are sending are very likely part of the windows
charset, aka, cp 1252.
There is no support for that right now, but it is quite is easy to
add it:
in xmlrpc.inc, on line 152, an array is already defined with the
necessary translation. Using array_keys() and array_values() on it,
you can modify function xmlrpc_encode_entitites(), adding a new case:
case 'CP1252_US-ASCII':
$escaped_data = str_replace(array('', '', ', '',
''), array('amp;', 'quot;', 'apos;', 'lt;', 'gt;'), $data);
$escaped_data =
str_replace($GLOBALS['xml_iso88591_Entities']['in'],
$GLOBALS['xml_iso88591_Entities']['out'], $escaped_data);
$escaped_data =
str_replace(array_keys(array_keys($GLOBALS['$cp1252_to_xmlent'])),
array_values($GLOBALS['$cp1252_to_xmlent']), $escaped_data);
break;
then of course you have to declare your internal encoding as CP1252
... and maybe check out if there is any decoding function to be
patched...
bye
Gaetano
Hi,
I have an encoding problem of some sort. The data (strings) I'm
sending through xmlresp contains some really nasty characters (e.g.
• „ “ …) and breaks the XML parser on the client side. Most of the
characters get automatically converted to their corresponding XML
entities by you library, but not those listed above.
How can I convert them so that my XML parser doesn't break? (I can
verify it's broken in Internet Explorer, which probably uses the
same parser)
Best regards,
Matthias Korn
___
phpxmlrpc mailing list
phpxmlrpc@lists.usefulinc.com
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
___
phpxmlrpc mailing list
phpxmlrpc@lists.usefulinc.com
http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
