[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Phpgroupware-developers] XMLRPC: the simple CLIENT example works "local

From: BOSSER Michel
Subject: [Phpgroupware-developers] XMLRPC: the simple CLIENT example works "locally" with PhP 4
Date: Sun, 24 Feb 2002 23:55:37 +0100 (MET)

Jean Eric WROTE:
>I found that phpGW was unable to get the user id 
>with the kp3/sessionid. I think that's a DB specific thing and php4 
>session can not handle it.

Here is A method to gain inspiration from to get 
a kd3/sessionid access in the simple client/findState example.
for which we had an UNAUTHORIZED access from the "server" before
finding (should I say "dicovering") the trick bellow.

We are using KDE and PhP 4 and, as we did not find much 
info in the forums, we've spent quite a long time on it, 
so we hope it'll be useful to you and to the XMLRPC community.

We understood many things during our blind "hare and hounds" week-end:

- the demos on usefulinc/demo work perfectly well remotely but
to have them working locally is another problem,
- following the O'REILLY link to the JellyFish book, and noticing 
how well the XMLRPC/JAVA cooperation was described in the example chapter, 
we supposed that all the commented steps we had been desperatly 
looking for where undoubtedly perfectly described in the JELLYFISH book chap 5
for Php.

So it is a shame that the XML-RPC installation kit is only an appendix of the 
we cannot get within our 48h deadline (we are students).
Consequently, is it possible to have what follows included
in the next XMLRPC package to avoid the same hassle to newcomers ?

+++++++++++++++++++++ Explained "with hands" +++++++++++++++++++++++++++ 
The general idea is that, for the simple client example,
/phpgroupware/xmlrpc/client.php  does not access 
/phpgroupware/xmlrpc/server.php at all. 
It uses the interface program /phpgroupware/xmlrpc.php to access the server 
methods included/dissimulated in /phpgroupware/pgpgwapi/inc/xmlrpc.interop.php
 through a KD3/sessionId key.
The key couple generation proceeds ONLY if you uncomment 
        // include(PHPGW_API_INC . '/xmlrpc.interop.php
in /phpgroupware/xmlrpc.php     
giving you acces to the server functions of this interop file.
Then as a normal server, the request result is sent back to the client

(1) I did not take sufficient time to study
/phpgroupware/xmlrpc/server.php but as far as the diff file between it
and /phpgroupware/pgpgwapi/inc/xmlrpc.interop.php is concerned, 
the former contains numerous extra global variable (to work more 
"independently" ??)

For us, this lock being released, things should go more easily now.


From: Jean-Eric Cuendet <address@hidden>
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.8) Gecko/20020205
X-Accept-Language: en-us
MIME-Version: 1.0
To: address@hidden
Content-Transfer-Encoding: 7bit
Subject: [Phpgroupware-developers] XMLRPC : Success! (At last...)
X-BeenThere: address@hidden
X-Mailman-Version: 2.0.5
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <>, 
List-Id: <>
List-Archive: <>
Date: Sun, 24 Feb 2002 20:25:19 +0100
X-Virus-Scanned: by amavisd-milter ( at

I was able to get addresses from phpGW through XMLRPC. The 
UNAUTHENTICATED problem I had was due as using the php4 session handling 
instead of the DB one. I found that phpGW was unable to get the user id 
with the kp3/sessionid. I think that's a DB specific thing and php4 
session can not handle it.

So, now it works for me after a lot of testing. I'll continue by trying 
to make it working with XMLRPC-C++ to use with KDE. My goal is to make a 
KIO-Slave for KDE to phpGW (just as the IMAP one).
Then, KDE apps (Kalendar, KAddressbook, etc...) could use it to get its 
informations from phpGW.

At the end what do you think of the idea of having the auth strings in 
the function parameters instead of in the HTTP header? I think it would 
be easier for everyone and the already existing APIs would be usable 
without patching.

Thanks and bye.

Phpgroupware-developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]