#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass docbook
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Title
eGroupWare XML-RPC/SOAP Methodology
\layout Author
(C) 2001-2004 Miles Lott
\layout Author
milos@groupwhere.org
\layout Date
August 23, 2001 and December 29, 2003
\layout Standard
additions made September 3, 2001.
\layout Standard
This document is very preliminary, but describes a working system.
\layout Section
System level requests
\layout Subsection
Login and authentication
\layout Standard
Authentication for user logins is handled internally no differently than
for the typical eGroupWare login via web browser.
Server logins, added for XML-RPC and SOAP, are only slightly different.
For either protocol, user and server login and authentication and subsequent
requests are handled by their respective server apps, xmlrpc.php and soap.php.
A server is identified by a custom HTTP header, without which a normal
user login will be undertaken.
\layout Standard
A client or server sends the appropriate XML-RPC or SOAP packet containing
host, user, and password information to the phpgw server.
The server then assigns a sessionid and key, which is returned to the client
in the appropriate format.
\layout Standard
Our current method for authenticating requests after successful login is
via the Authorization: Basic HTTP header to be sent by the client or requesting
server.
The format of this header is a base64 encoding of the assigned sessionid
and kp3 variables, seperated by a ':'.
\layout Standard
Further security may be obtained by using SSL on the client and server.
In the future, we may encrypt/descrypt the data on either end, or at least
provide this as an option.
The sessionid and key variables will make this possible, and relatively
secure.
\layout Subsubsection
system.login
\layout Standard
The first request a client will make is the system.login method.
Here is a sample of a server login packet in XML-RPC:
\layout Code
\layout Code
\layout Code
system.login
\layout Code
\layout Code
\layout Code
\layout Code
server_name
\layout Code
my.host.name
\layout Code
\layout Code
username
\layout Code
bubba
\layout Code
\layout Code
password
\layout Code
gump
\layout Code
\layout Code
\layout Code
\layout Code
\layout Standard
And the same in SOAP:
\layout Code
\layout Code
\layout Code
\layout Code
my.host.name
\layout Code
bubba
\layout Code
gump
\layout Code
\layout Code
\layout Code
\layout Standard
The same style of packet would be required for a user/client login.
A successful login should yield the following reply:
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
sessionid
\layout Code
cf5c5534307562fc57915608377db007
\layout Code
\layout Code
kp3
\layout Code
2fe54daa11c8d52116788aa3f93cb70e
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Standard
And a failed login:
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
GOAWAY
\layout Code
XOXO
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Standard
eqweqw
\layout Subsubsection
system.logout
\layout Standard
Logout:
\layout Code
\layout Code
\layout Code
system.logout
\layout Code
\layout Code
\layout Code
sessionid
\layout Code
ea35cac53d2c12bd05caecd97304478a
\layout Code
\layout Code
kp3
\layout Code
4f2b256e0da4e7cbbebaac9f1fc8ca4a
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Standard
Logout worked:
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
GOODBYE
\layout Code
XOXO
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Section
Business layer requests
\layout Standard
Once a successful login return packet has been received and sessionid/kp3
have been extracted, every subsequent packet sent to the phpgroupware server
must be preceded by an Authorization header.
Here is a sample header:
\layout Code
POST /phpgroupware/xmlrpc.php HTTP/1.0
\layout Code
User-Agent: PHP XMLRPC 1.0
\layout Code
Host: my.local.host
\layout Code
Authorization: Basic ZDgxNDIyZDRkYjg5NDEyNGNiMzZlMDhhZTdlYzAxZmY6NTU3YzkyYjBmNGE
4ZDVlOTUzMzI2YmU2OTQyNjM3YjQ=
\layout Code
Content-Type: text/xml
\layout Code
Content-Length: 875
\layout Standard
The longish string is a base64 encoding of the $sessionid .
':' .
$kp3.
For now this is our only supported authentication method.
Additional methods would probably also affect the methodCalls.
This is certainly open to discussion.
Following is a typical request for some contact data:
\layout Code
\layout Code
\layout Code
addressbook.boaddressbook.read_entries
\layout Code
\layout Code
\layout Code
\layout Code
start
\layout Code
1
\layout Code
\layout Code
limit
\layout Code
5
\layout Code
\layout Code
fields
\layout Code
\layout Code
n_given
\layout Code
n_given
\layout Code
\layout Code
n_family
\layout Code
n_family
\layout Code
\layout Code
\layout Code
\layout Code
query
\layout Code
\layout Code
\layout Code
filter
\layout Code
\layout Code
\layout Code
sort
\layout Code
\layout Code
\layout Code
order
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Standard
Successful response:
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
\layout Code
0
\layout Code
\layout Code
id
\layout Code
1
\layout Code
\layout Code
lid
\layout Code
\layout Code
\layout Code
tid
\layout Code
n
\layout Code
\layout Code
owner
\layout Code
500
\layout Code
\layout Code
access
\layout Code
private
\layout Code
\layout Code
cat_id
\layout Code
1
\layout Code
\layout Code
n_given
\layout Code
Alan
\layout Code
\layout Code
\layout Code
\layout Code
1
\layout Code
\layout Code
id
\layout Code
2
\layout Code
\layout Code
lid
\layout Code
\layout Code
\layout Code
tid
\layout Code
n
\layout Code
\layout Code
owner
\layout Code
500
\layout Code
\layout Code
access
\layout Code
private
\layout Code
\layout Code
cat_id
\layout Code
1
\layout Code
\layout Code
n_given
\layout Code
Andy
\layout Code
\layout Code
\layout Code
\layout Code
...
\layout Standard
Unauthorized access attempt returns:
\layout Code
\layout Code
\layout Code
\layout Code
UNAUTHORIZED
\layout Code
\layout Code
\layout Code
\layout Section
More to come...
\layout Standard
Documenting every single call will be difficult, but should be done.
In leiu of this, please see the class.bo{APPNAME}.inc.php files in each applicatio
n/inc directory in the egroupware cvs.
In this file will be a list_methods() function, which returns the information
to the server about input/output structure for each call.
If the file does not have this function, then it is not yet workable via
this interface.
As for the actual functions, they are also in this file.
Generally, they will all accept associative array input and return same,
but not always.
This code is in flux, have fun.
\the_end