phpxmlrpc-devel — Discussion list for developers on XML-RPC for PHP

[phpxmlrpc-devel] is this list working?

[lukasz m. <lu...@ma...>]

i have posted message about float numbers at 2003-01-17 and 
i can't see it at sourceforge.net mailarchive.

so i'm wondering if those mail successfull arrived to list.

had anybody read mail about float/double numbers encoding?

regards


maHo

[phpxmlrpc-devel] double/float number encoding

[lukasz m. <lu...@ma...>]

there is a problem with very big(or very small) float 
numbers. php automagically converts it to scientific number
for example
	1300000000000000000000 to 1.3e21

xmlrpc server accepts it as valid double value, but xmlrpc 
client "converts" it to ERROR_NON_NUMERIC_FOUND, because it 
doesn't match to "^[0-9\+\-\.]+$" regexp.
	i see 2 solutions:
1) let php server accept scientific format, and replace 
regexp based check by is_float(). but xmlrpc specification 
is unclear for me, and i'm not sure if it allow scientific 
format of double number.

2) convert every big or small double to normal format using 
sprintf and proper precision modifier. but it can generate 
amount of unneeded data (1.3e55 takes 6 bytes, 13000....0000 
takes 56 bytes).


what do you think about it?


pozdrav

maHo

[phpxmlrpc-devel] Missing SSL Option when semnding xmlrpcmsg?

[Gaetano G. <giu...@se...>]

Hello,

I'm just taking my first steps into the world of secure communication, =
so excuse me if this is absolutely irrelevant.

When sending an xmlrpcmsg over https, the xmlrpc_client object has =
methods that allow it to check the peer certificate validity.
But there is no option to set the CA certificate to be used in the =
verification process (e.g. if I use a certificate signed by my company's =
CA, which is not trusted by anyone in the world but me).
I figured out that the curl option to set CA certificates has to be set =
between the calls to curl_init and curl_close, so the only place to put =
it is in the xmlrpc_client->sendpayloadhttps method.

Is this correct? In that case maybe we should add an =
xmlrpc_client->setCAInfo method. (This would be better than setting =
CURLOPT_CAPATH, that is not supported under windows).


Thanks, gaetano

R: [phpxmlrpc-devel] BUG in release 1.0.99!!!

[Gaetano G. <giu...@se...>]

I noticed your patch on sf as soon as I finished posting my mail, DOH.
Thanks for the clear explanation.

I was thinking about a way to 'throw errors' if the XML-RPC param values =
do not match the declared data type. Right now this is checked for INT =
values, but not for other data types (IIRC the spec), which lacks a bit =
in coherence: why shuld the server tell the client he's calling an =
unsupported method if the function call gets wrong the number/type of =
parameters and not if it passes unlawful parameter values?.

What I had in mind is allowing the coder to decide how to respond to =
malformed data, by e.g. providing an error handling function of the =
xmlrpcserver class (that could be overriden if needed by the library =
user). Or a property of the xmlrpcserver/client class could decide =
wheter to enforce strict type checking or not.

The $_xh[$parser]['isf'] variable looks like  an appropriate place to =
store the information on 'bad param data in xml', but the handling of =
errors would have to be done in xmlrpcmsg->parseresponse and =
xmlrpcserver->parserequest (an involved change).

Any thoughts/comments?

regards
Gaetano

> Gaetano Giunta wrote:
> > xmlrpc->faultcode() returns -1 on a succesful function call!!!
> >=20
> > This is in contrast with the manual and with previous behaviour.
> >=20
>=20
> probably you're talking about my "feature".
> in some situations( when mehtod throws error, but=20
> faultcode=3D=3D0, in example client(phpxmlrpc)=3D>server(java=20
> xmlrpc.apache.org)) php client thinks there is no error.=20
> (because faultcode() test returns 0). so i made patch which=20
> fixes it, and returns fault -1 (which is properly recognized=20
> by client).
>=20
> this patch was applied to cvs.
>=20
> but i realized that i made mistake in that (in some versions=20
> of php doesn't work). i fixed it immediately and posted next=20
> patch, but for unknown reasons this wasn't imcluded to cvs.
>=20
> so i posted it to
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D6190
> 08&group_id=3D34455&atid=3D411302
>=20
> hope it helps
>=20
> regards
>=20
> maHo
>=20
>=20

Re: [phpxmlrpc-devel] BUG in release 1.0.99!!!

[lukasz m. <lu...@ma...>]

Gaetano Giunta wrote:
 > xmlrpc->faultcode() returns -1 on a succesful function 
call!!!
 >
 > This is in contrast with the manual and with previous 
behaviour.
 >

probably you're talking about my "feature".
in some situations( when mehtod throws error, but
faultcode==0, in example client(phpxmlrpc)=>server(java
xmlrpc.apache.org)) php client thinks there is no error.
(because faultcode() test returns 0). so i made patch which
fixes it, and returns fault -1 (which is properly recognized
by client).

this patch was applied to cvs.

but i realized that i made mistake in that (in some versions
of php doesn't work). i fixed it immediately and posted next
patch, but for unknown reasons this wasn't imcluded to cvs.

so i posted it to
https://sourceforge.net/tracker/index.php?func=detail&aid=619008&group_id=34455&atid=411302

hope it helps

regards

maHo

R: [phpxmlrpc-devel] BUG in release 1.0.99!!!

[Gaetano G. <giu...@se...>]

OOPS, just noticed there's a patch already in sourceforge.

Sorry: forget previous post

Gaetano

[phpxmlrpc-devel] BUG in release 1.0.99!!!

[Gaetano G. <giu...@se...>]

xmlrpc->faultcode() returns -1 on a succesful function call!!!

This is in contrast with the manual and with previous behaviour.

Besides, why not set $_xh[$parser]['isf'] =3D 1 in function xmlrpc_ee =
when there an invalid integer value is found???

gaetano

[phpxmlrpc-devel] Empty zip file on Sourceforge

[Gaetano G. <giu...@se...>]

The zip file of release 1.0.99 is empty (it contains only an empty =
dierctory).

Bye, Gaetano

[phpxmlrpc-devel] [Fwd: XML-RPC Fix]

[Edd D. <ed...@us...>]

any opinions on this patch?  seems uncontroversial enough to me.

-----Forwarded Message-----

From: Edgar <e....@mo...>
To: ed...@us...
Subject: XML-RPC Fix
Date: 08 Nov 2002 07:13:00 -0800

Hi !

I made a change in your xmlrpc.inc

in line 301 was this regular expresion: "^\-?[0123456789 \t\.]+$
I changed it to: ^\-?[-eE0123456789 \t\.]+$

befor where errors when receiving a double eg. 1.2345E-06

now it works

bye Edgar

[phpxmlrpc-devel] [Fwd: about: phpxmlrpc project]

[Edd D. <ed...@us...>]

-----Forwarded Message-----

From: Nikolajus Krauklis <nik...@us...>
To: ed...@us...
Subject: about: phpxmlrpc project
Date: 05 Nov 2002 05:02:05 -0800

there is open BUG in this project,
i comment this bug and want to commit patch to=20
repository

this error come out whan you are using xmlrpc.inc=20
with error_reporting(E_ALL); in line 333;

this can be fixed with adding this line before 333=20
line:
// fix for E_ALL error reporting
!isset($_xh[$parser]['ac']) && $_xh[$parser]['ac'] =3D '';

thats all
regards
--=20
Edd Dumbill ----| phone: +44 1904 427740 fax: +44 8709 909625 |-----
 | Managing Editor, XML.com, XMLhack.com  --  Chair, XML Europe 2003
 | I PGP sign my email; more info at http://heddley.com/edd/pgp.html

Re: [phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Justin R. M. <in...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Said Andres Salomon on Wed, Oct 30, 2002 at 03:08:08PM -0500:

> adding SSLOption +CompatEnvVars in order to obtain the client's CN
> (and thus differentiate clients).  

Good idea -- might prove easier to do that. 

- -- 
[!] Justin R. Miller <in...@co...>
    Encrypted email preferred (key 0xC9C40C31)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE9wD+G94d6K8nEDDERAsaaAJ43uq04FPLVbX8VwrecEi0qYHbXdwCgjFAm
HeNF6KKGreLQfMIzEXDFnVE=
=2xje
-----END PGP SIGNATURE-----

Re: [phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Andres S. <dil...@mp...>]

Thanks for pointing this out.  Documentation seems to be sparse, but it
looks like it may be possible for us to use this by requiring clients to
have been signed by a trusted CA (basically, the server's CA), and
adding SSLOption +CompatEnvVars in order to obtain the client's CN (and
thus differentiate clients).  I'll play with it a bit.

On Wed, Oct 30, 2002 at 07:56:12AM -0500, Justin R. Miller wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Said Andres Salomon on Wed, Oct 30, 2002 at 02:23:57AM -0500:
> 
> > The idea is to identify where a request came from; the cert only
> > verifies the server, not the client.  Also, the cert is generally
> > self-signed, so I have no reason to trust it.  I was thinking openssl
> > signing, not gnupg.
> 
> Actually the certificate support that is in there is client and server
> certificates, i.e. the *client* has to have the right certificate in
> order to get interact with the server's certificate.  This is an
> alternative to HTTP(S) Basic or Digest username and password
> authentication.  In Edd's documentation for the *client* methods, just
> after the setCredentials method (i.e. username/password auth), there is
> a section for the setCertificate method.  The functionality is described
> in the 'HTTPS' section for the cURL docs at:
> 
>     http://curl.haxx.se/docs/readme.curl.html
> 
> Furthermore, here's a post from this list ;-)
> 
>     http://www.mail-archive.com/php...@us.../msg00069.html
> 
> Most people don't use this feature of HTTPS, but the idea is that *both*
> the client and server share 'halves' of a private certificate (the
> client's being PEM-formatted), and the client is not allowed to
> establish a connection without the proper certificate.  Companies will
> occasionally use this, for example installing a client certificate on
> the workstations and then having them connect to the server via HTTPS.
> The user does not need to worry about authentication, as the browsers
> and server take care of this via the private certificates.  
> 
> However, I'm not sure that the clients can all have different
> certificates, or if they all share the same file.  You would have to
> look into the spec for HTTPS if this was a concern.  
> 
> > (Hi Justin!  Did you hear about our gig thanksgiving weekend yet?)
> 
> Yep :-)  We'll have to carry this further off-list though ;-)
> 
> - -- 
> [!] Justin R. Miller <in...@co...>
>     Encrypted email preferred (key 0xC9C40C31)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (FreeBSD)
> 
> iD8DBQE9v9bs94d6K8nEDDERAmRLAJ4ovxP6K2Jyd0N5w6l3+0RLhr6fHQCeO9V3
> gsr79b8MSt9yh6YyqHPGwVI=
> =8YWA
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> phpxmlrpc-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpxmlrpc-devel

-- 
It's not denial.  I'm just selective about the reality I accept.
	-- Bill Watterson

Re: [phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Justin R. M. <in...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Said Andres Salomon on Wed, Oct 30, 2002 at 02:23:57AM -0500:

> The idea is to identify where a request came from; the cert only
> verifies the server, not the client.  Also, the cert is generally
> self-signed, so I have no reason to trust it.  I was thinking openssl
> signing, not gnupg.

Actually the certificate support that is in there is client and server
certificates, i.e. the *client* has to have the right certificate in
order to get interact with the server's certificate.  This is an
alternative to HTTP(S) Basic or Digest username and password
authentication.  In Edd's documentation for the *client* methods, just
after the setCredentials method (i.e. username/password auth), there is
a section for the setCertificate method.  The functionality is described
in the 'HTTPS' section for the cURL docs at:

    http://curl.haxx.se/docs/readme.curl.html

Furthermore, here's a post from this list ;-)

    http://www.mail-archive.com/php...@us.../msg00069.html

Most people don't use this feature of HTTPS, but the idea is that *both*
the client and server share 'halves' of a private certificate (the
client's being PEM-formatted), and the client is not allowed to
establish a connection without the proper certificate.  Companies will
occasionally use this, for example installing a client certificate on
the workstations and then having them connect to the server via HTTPS.
The user does not need to worry about authentication, as the browsers
and server take care of this via the private certificates.  

However, I'm not sure that the clients can all have different
certificates, or if they all share the same file.  You would have to
look into the spec for HTTPS if this was a concern.  

> (Hi Justin!  Did you hear about our gig thanksgiving weekend yet?)

Yep :-)  We'll have to carry this further off-list though ;-)

- -- 
[!] Justin R. Miller <in...@co...>
    Encrypted email preferred (key 0xC9C40C31)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE9v9bs94d6K8nEDDERAmRLAJ4ovxP6K2Jyd0N5w6l3+0RLhr6fHQCeO9V3
gsr79b8MSt9yh6YyqHPGwVI=
=8YWA
-----END PGP SIGNATURE-----

Re: [phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Andres S. <dil...@mp...>]

The idea is to identify where a request came from; the cert only
verifies the server, not the client.  Also, the cert is generally
self-signed, so I have no reason to trust it.  I was thinking openssl
signing, not gnupg.

(Hi Justin!  Did you hear about our gig thanksgiving weekend yet?)

On Tue, Oct 29, 2002 at 08:29:40AM -0500, Justin R. Miller wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Apologies if this should be kept on the -devel list.  Feel free to
> correct followups.  And I believe that Andres is on at least the -devel
> list.  
> 
> I was just curious what advantage (besides the obvious encryption
> strength improvement) PGP/GnuPG support in these XML-RPC bindings has
> over the HTTPS/cURL-based certificate support that myself and Garrett
> Rooney added.  
> 
> I suppose that with PGP you've got a certification as to the
> authenticity of the client, and not just the security of the protocol
> and authrorization to exchange.  But it seems like this might be pretty
> hackish to get into HTTP.  
> 
> Then again, you guys at Voxel could be up to anything ;-)
> 
> (BTW, Hi Andres!)
> 
> Said Edd Dumbill on Tue, Oct 29, 2002 at 07:48:00AM +0000:
> 
> > Any comments?  Please be sure to CC Andres.
> > 
> > -----Forwarded Message-----
> > 
> > From: Andres Salomon <dil...@vo...>
> > To: ed...@us...
> > Subject: xmlrpc signing
> > Date: 29 Oct 2002 02:41:38 -0500
> > 
> > I'm attempting to add key signing to your xmlrpc library (I'll feed
> > changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
> > sent, it is serialized, a private key is used to generate a signature of
> > the serialized data, and both are sent to the xmlrpc server.  The server
> > uses the client's public key to verify that the msg came from the actual
> > client; if verification is sucessful, decode the xmlrpcmsg as normal.
> > 
> > My hang-up is how to send the payload signature.  The way I'd prefer to do it
> > is a simple form variable; the XMLRPC spec states that the xmlrpc
> > message is the body of a HTTP-POST request, so I figure that leaves
> > HTTP-GET available for (ab)use.  I'd like to do this in a manner that
> > works with other xmlrpc implementations (if not supporting the
> > verification, silently ignoring the signature).
> > 
> > Have you heard of any other implementations that allow this, or similar
> > workarounds (perhaps passing the signature elsewhere)?  Do you have any
> > suggestions?
> > 
> > -- 
> > It's not denial.  I'm just selective about the reality I accept.
> > 	-- Bill Watterson
> > 
> 
> 
> 
> 
> - -- 
> [!] Justin R. Miller <in...@co...>
>     Encrypted email preferred (key 0xC9C40C31)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (FreeBSD)
> 
> iD8DBQE9vo1E94d6K8nEDDERApZ7AJ9oQQMTUlpHUqimkqlM49ghXybuywCZATbT
> XL5jxHSFv85a82cNQhkw1Lc=
> =14gr
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> phpxmlrpc-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpxmlrpc-devel

-- 
It's not denial.  I'm just selective about the reality I accept.
	-- Bill Watterson

Re: [phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Ryan H. <rh...@is...>]

Hi,

I am a contributor to the Apache XML-RPC project, which is a Java 
library for XML-RPC server and client.  Members of our list have 
mentioned this requirement and have looked for ways to accomplish it 
with interoperability in mind.

The solution you propose seems proprietary and not designed for interop. 
 Have you considered any proposals by the XML-Signature Working Group at 
http://www.w3.org/Signature/ or the XML-Encryption Working Group at 
http://www.w3.org/Encryption/2001/ ?

Basically, it might be a good idea to design these solutions with 
interop in mind from the beginning.  I must confess that our project has 
not produced any code with digital signatures or encryption integrated, 
but there is an independent interceptors patch that has allowed at least 
one developer to buiild in his own proprietary encryption code for use 
with Kerberos.

I monitor this list and would be interested in more discussion in this area.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Miles Lott wrote:

>>I'm attempting to add key signing to your xmlrpc library (I'll feed
>>changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
>>sent, it is serialized, a private key is used to generate a signature of
>>the serialized data, and both are sent to the xmlrpc server.  The server
>>uses the client's public key to verify that the msg came from the actual
>>client; if verification is sucessful, decode the xmlrpcmsg as normal.
>>    
>>
>
>In phpgroupware/groupwhere, a login function is called first.  This
>generates a sessionid and key as with their normal browser login.  The
>sessionid/key are then sent in Authorization: Basic header to verify
>subsequent requests.  Lastly, a logout packet is sent to clear the user
>session.  Public/private keys would be cool, though.  I had not done
>much in that implementation to encrypt subsequent requests...
>
>  
>
>>My hang-up is how to send the payload signature.  The way I'd prefer to do it
>>is a simple form variable; the XMLRPC spec states that the xmlrpc
>>message is the body of a HTTP-POST request, so I figure that leaves
>>HTTP-GET available for (ab)use.  I'd like to do this in a manner that
>>works with other xmlrpc implementations (if not supporting the
>>verification, silently ignoring the signature).
>>    
>>
>
>I am not absolutely certain, but in my simple tests trying to write a
>php-based daemon for xml-rpc I found that GET or POST requests send the
>entire set of values on one line.  The difference being the first line
>of the request specifying GET or POST.  In this library at least, the
>variable HTTP_RAW_POST_DATA is used to decode the entire request.  This
>is most likely because PHP does not know what to do with a POST or GET
>that is multiline as with XML-RPC.  In other words, I think you could
>still use POST.  iirc, it looks something like this:
>
>POST /RPC2 HTTP/1.0
>User-Agent: Frontier/5.1.2 (WinNT)
>Host: betty.userland.com
>Content-Type: text/xml
>Content-length: XXX
>user=bob&password=secret
>
><?xml version="1.0"?>
><methodCall>
>  <methodName>examples.getStateName</methodName>
>  <params>
>    <param>
>      <value><i4>41</i4></value>
>    </param>
>  </params>
></methodCall>
>
>
>  
>
>>Have you heard of any other implementations that allow this, or similar
>>workarounds (perhaps passing the signature elsewhere)?  Do you have any
>>suggestions?
>>    
>>
>
>This could be sent in an Authorization: Basic header so long as the
>server knows how to decode it.  I wrote this into phpgroupware and now
>groupwhere's implementation of its XML-RPC server since I did not find
>any other way.  Your work would be very welcome if it first does not
>break other implementations (of course).
>

[phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Miles L. <mi...@gr...>]

> I'm attempting to add key signing to your xmlrpc library (I'll feed
> changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
> sent, it is serialized, a private key is used to generate a signature of
> the serialized data, and both are sent to the xmlrpc server.  The server
> uses the client's public key to verify that the msg came from the actual
> client; if verification is sucessful, decode the xmlrpcmsg as normal.

In phpgroupware/groupwhere, a login function is called first.  This
generates a sessionid and key as with their normal browser login.  The
sessionid/key are then sent in Authorization: Basic header to verify
subsequent requests.  Lastly, a logout packet is sent to clear the user
session.  Public/private keys would be cool, though.  I had not done
much in that implementation to encrypt subsequent requests...

> My hang-up is how to send the payload signature.  The way I'd prefer to do it
> is a simple form variable; the XMLRPC spec states that the xmlrpc
> message is the body of a HTTP-POST request, so I figure that leaves
> HTTP-GET available for (ab)use.  I'd like to do this in a manner that
> works with other xmlrpc implementations (if not supporting the
> verification, silently ignoring the signature).

I am not absolutely certain, but in my simple tests trying to write a
php-based daemon for xml-rpc I found that GET or POST requests send the
entire set of values on one line.  The difference being the first line
of the request specifying GET or POST.  In this library at least, the
variable HTTP_RAW_POST_DATA is used to decode the entire request.  This
is most likely because PHP does not know what to do with a POST or GET
that is multiline as with XML-RPC.  In other words, I think you could
still use POST.  iirc, it looks something like this:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: XXX
user=bob&password=secret

<?xml version="1.0"?>
<methodCall>
  <methodName>examples.getStateName</methodName>
  <params>
    <param>
      <value><i4>41</i4></value>
    </param>
  </params>
</methodCall>


> Have you heard of any other implementations that allow this, or similar
> workarounds (perhaps passing the signature elsewhere)?  Do you have any
> suggestions?

This could be sent in an Authorization: Basic header so long as the
server knows how to decode it.  I wrote this into phpgroupware and now
groupwhere's implementation of its XML-RPC server since I did not find
any other way.  Your work would be very welcome if it first does not
break other implementations (of course).

-- 

Miles Lott
GroupWhere
http://groupwhere.org

[phpxmlrpc-devel] Re: [phpxmlrpc] [Fwd: xmlrpc signing]

[Justin R. M. <in...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Apologies if this should be kept on the -devel list.  Feel free to
correct followups.  And I believe that Andres is on at least the -devel
list.  

I was just curious what advantage (besides the obvious encryption
strength improvement) PGP/GnuPG support in these XML-RPC bindings has
over the HTTPS/cURL-based certificate support that myself and Garrett
Rooney added.  

I suppose that with PGP you've got a certification as to the
authenticity of the client, and not just the security of the protocol
and authrorization to exchange.  But it seems like this might be pretty
hackish to get into HTTP.  

Then again, you guys at Voxel could be up to anything ;-)

(BTW, Hi Andres!)

Said Edd Dumbill on Tue, Oct 29, 2002 at 07:48:00AM +0000:

> Any comments?  Please be sure to CC Andres.
> 
> -----Forwarded Message-----
> 
> From: Andres Salomon <dil...@vo...>
> To: ed...@us...
> Subject: xmlrpc signing
> Date: 29 Oct 2002 02:41:38 -0500
> 
> I'm attempting to add key signing to your xmlrpc library (I'll feed
> changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
> sent, it is serialized, a private key is used to generate a signature of
> the serialized data, and both are sent to the xmlrpc server.  The server
> uses the client's public key to verify that the msg came from the actual
> client; if verification is sucessful, decode the xmlrpcmsg as normal.
> 
> My hang-up is how to send the payload signature.  The way I'd prefer to do it
> is a simple form variable; the XMLRPC spec states that the xmlrpc
> message is the body of a HTTP-POST request, so I figure that leaves
> HTTP-GET available for (ab)use.  I'd like to do this in a manner that
> works with other xmlrpc implementations (if not supporting the
> verification, silently ignoring the signature).
> 
> Have you heard of any other implementations that allow this, or similar
> workarounds (perhaps passing the signature elsewhere)?  Do you have any
> suggestions?
> 
> -- 
> It's not denial.  I'm just selective about the reality I accept.
> 	-- Bill Watterson
> 




- -- 
[!] Justin R. Miller <in...@co...>
    Encrypted email preferred (key 0xC9C40C31)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE9vo1E94d6K8nEDDERApZ7AJ9oQQMTUlpHUqimkqlM49ghXybuywCZATbT
XL5jxHSFv85a82cNQhkw1Lc=
=14gr
-----END PGP SIGNATURE-----

[phpxmlrpc-devel] [Fwd: xmlrpc signing]

[Edd D. <ed...@us...>]

Any comments?  Please be sure to CC Andres.

-----Forwarded Message-----

From: Andres Salomon <dil...@vo...>
To: ed...@us...
Subject: xmlrpc signing
Date: 29 Oct 2002 02:41:38 -0500

I'm attempting to add key signing to your xmlrpc library (I'll feed
changes back upstream once I'm done).  Once an xmlrpcmsg is about to be
sent, it is serialized, a private key is used to generate a signature of
the serialized data, and both are sent to the xmlrpc server.  The server
uses the client's public key to verify that the msg came from the actual
client; if verification is sucessful, decode the xmlrpcmsg as normal.

My hang-up is how to send the payload signature.  The way I'd prefer to do =
it
is a simple form variable; the XMLRPC spec states that the xmlrpc
message is the body of a HTTP-POST request, so I figure that leaves
HTTP-GET available for (ab)use.  I'd like to do this in a manner that
works with other xmlrpc implementations (if not supporting the
verification, silently ignoring the signature).

Have you heard of any other implementations that allow this, or similar
workarounds (perhaps passing the signature elsewhere)?  Do you have any
suggestions?

--=20
It's not denial.  I'm just selective about the reality I accept.
	-- Bill Watterson

[phpxmlrpc-devel] How to send a pre formatted xml-rpc query string?

[Gaetano G. <giu...@se...>]

Say I have a pre-formatted xml-rpc method call that I want to replicate, =
complete with parameters etc...
I see no methods either in the xmlrpcclient or in the xmlrpcmsg classes =
to start off the xmlrpc call with a pre-formatted text string (a la =
ParseResponseFile).
Am I missing something or is this something that could be added to the =
lib?

Thanks, Gaetano

Re: [phpxmlrpc-devel] time for a new release

[Gaetano G. <giu...@se...>]

> Have you guys been running the CVS version?  How stable's it been?
>=20
> Given that, do we need a 1.1beta release or can we drop a 1.1 release?

Not to troll... but what about previous post concerning =
$xmlrpc_defencoding?

a) Does anyone think it would be a good idea to have an xmlrpc server =
that accepts different charset encodings for requests - not only the one =
specified in a global variable ?

My idea is: the server tries to get the charset encoding info from the =
HTTP post request and (possibly) formats the answer in the same charset =
encoding.

b) I am more convinced than ever than standard encoding (i.e. if not =
specified) for XML sent as HTTP text/whatever should be iso-8859-1, NOT =
utf-8 (see the w3c note about preferred methods for sending xhtml), so =
the default $xmlrpc_defencoding should be changed - but I am pretty sure =
that 'breaking the api' this way is bad

Beside, gonna download the cvs stuff and check it out (I wanna play).
IMHO I'd suggest a beta release before 1.1

Gaetano

[phpxmlrpc-devel] time for a new release

[Edd D. <ed...@us...>]

It feels like it's time for a new release.  So, we need the following
info...

Have you guys been running the CVS version?  How stable's it been?

Given that, do we need a 1.1beta release or can we drop a 1.1 release?

What documentation needs updating?

Who wants to play?

:-)

-- Edd

[phpxmlrpc-devel] patch: error with fault code=0 recognize

[maHo <lu...@ma...>]

last patch(included in cvs tree) i have send works well on php 4.0.6, 
but on other machine (with php 4.1.x) doesn't. seems to be difference in 
results of isset function. so i made next patch which solves this 
problem. this works on both versions i have. i think it can be safely 
included into cvs

regards

maHo

Re: [phpxmlrpc-devel] Interoperability

[Edd D. <ed...@us...>]

On Sun, 2002-09-29 at 19:31, Ryan Hoegg wrote:
> Hi Edd,
>=20
> I've been working on this some more and have formed my latest theory as=20
> to what's gone wrong.  I think both the Apache distribution and this one=20
> are breaking the HTTP 1.1 spec in RFC2616:
>=20
> You:
>  - Messages MUST NOT include both a Content-Length header field and a=20
> non-identity transfer-coding.
> and
> - The Content-Length header field MUST NOT be sent if these two lengths=20
> are different (i.e., if a Transfer-Encoding header field is present).

Hmm, that makes it an interesting problem to solve this end -- as this
behaviour is entirely dependent, as far as I can see, on the host web
server.  In my case, Apache 1.3.  The only thing I could think to do
would be to instruct users to ensure they force HTTP 1.0 on their
XML-RPC endpoint (I don't even know if this is possible, I've only ever
seen this enforced in Apache httpd via the BrowserMatch directive).

> Us:
>  - If the message does include a non-identity transfer-coding, the=20
> Content-Length MUST be ignored.
> and
> - If a message is received with both a Transfer-Encoding header field=20
> and a Content-Length header field, the latter MUST be ignored.

As obviously there appears to be no guarantee for you that servers using
PHP XML-RPC will do the right thing, and I don't appear to be able to
make a change to enforce it, then I think it's up to you...

All suggestions for workarounds welcome.

-- Edd=20

Re: [phpxmlrpc-devel] Interoperability

[Ryan H. <rh...@is...>]

Hi Edd,

I've been working on this some more and have formed my latest theory as 
to what's gone wrong.  I think both the Apache distribution and this one 
are breaking the HTTP 1.1 spec in RFC2616:

You:
 - Messages MUST NOT include both a Content-Length header field and a 
non-identity transfer-coding.
and
- The Content-Length header field MUST NOT be sent if these two lengths 
are different (i.e., if a Transfer-Encoding header field is present).

Us:
 - If the message does include a non-identity transfer-coding, the 
Content-Length MUST be ignored.
and
- If a message is received with both a Transfer-Encoding header field 
and a Content-Length header field, the latter MUST be ignored.

--
Ryan Hoegg
ISIS Networks


Edd Dumbill wrote:

>OK, I figured this out.  Your request header has HTTP/1.1 in it.  If
>that's what you send, that's what the web server expects you to speak!  
>
>The ones your program worked against worked because they don't implement
>HTTP/1.1.
>
>Change your request to HTTP/1.0, or implement HTTP/1.1 properly :)
>
>-- Edd
>  
>

[phpxmlrpc-devel] Proxy support

[<fre...@uo...>]

Hi all,

Is there any support to proxy (as Squid) in xmlrpc??


Regards,

            Flavio