openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxxx>]

Hi everybody!

Using the previously applied netsvc.ExportService API from 5.2, I have now an 
*alpha* version of the new RPC mechanism. Let's call it 'xmlrpc2'

The idea is that we separate the authentication procedure from the rpc 
function calls. That is, the arguments to service functions should no longer 
include the database, uid and password.

In network terms, this should /not/ help things much. I wouldn't expect more 
than 10% improvement (only 2 params get eliminated). But, with xmlrpc2 we pave 
the way for a more generic authentication API.

Having an authentication API, rather than username, password in each call, is 
the way to go for a more sophisticated security scheme. We can at any time 
replace my "Basic" authentication with some One Time Password algoritm (like 
the one from Cryptocamp) or even Kerberos or OpenID security! And all that, 
transparently to the netsvc code.

Technical detais.
-----------------
Since the 5.2 rpc restructuring, all xml-rpc calls have been routed from 
netsvc.OpenERPDispatcher to call ExportService.dispatch(), which then parses 
the 2-3 first arguments for credentials, according to the call. You would have 
noted the new_dispatch() function there.

Note also that we have used the MultiHTTPHandler class to allow multiple http 
services under the same server (aka 8069, 8071 ports).

For "xmlrpc2", we register 3 new paths in our http server, namely 
/xmlrpc2/pub/, /xmlrpc2/root/ and /xmlrpc2/db/ . We have to have 3 of them, 
since the path element is the best way for the HTTP code to know what realm of 
authentication it should ask for. I call those paths "authentication domains".

Taken from the code that already does the WebDAV authentication, I have 
registered those xmlrpc2 paths to apply the OpenERPAuthProvider, which means 
that they request Basic http authentication.

For each connection, the AuthProvider creates an AuthProxy, which lives 
throughout and can be passed down to each dispatch() call. So, the 
new_dispatch() is now able to get the (db, uid) pair from the AuthProxy, 
rather than the call arguments.

This code is parallel to the old xmlrpc one and doesn't break (hopefully) its 
functionality. So, you could point any xmlrpc or net-rpc client at the same 
server and still use it.

Client
----------
I have implemented that for the kde client so far, because that code had been 
easier to hack. 
The http Basic authentication lies in tiny_socket.py, at the addAuthTransport 
class. 
The connection was then hacked to use a more standardized api, and condsider 
the login() as a special rpc call (because it does more than the RPC level).

Using an "XmlRpc2Connection" class, calls now run through the 
"PersistentAuthTransport", which is bound to a single instance of the 
BasicAuthClient authenticator. 
Each time a new connection is done, the first call will require credentials 
through a 401 http response. Transparently, the transport will ask the 
BasicAuthClient for the appropriate http header line and offer the credentials.

Caveats, TODO
---------------------

This is an alpha version of the code. Some points need further development, to 
reach the old functionality.

- The database functions (not 'db' domain, but in the 'root' one) may need 
little attention, since they pass the credentials in an arbitrary way. 
Respectively, at the client(s), we need to make sure the values from the 
dialogs are passed down to the AuthClients
- The gtk client should be adapted.
- The web client may /not/ be adapted, since it nominally runs at the same 
machine as the server and cannot offer more security than the password 
authentication anyway.

- At both clients, we should have some fallback code, which will revert to the 
old xml-rpc if the '/xmlrpc2/..' paths don't work (they will return a 404 
response, easy to detect).
- We should audit the code to make sure the authentication cannot be bypassed, 
eg. with successive calls that contain "uid" for a persistent connection.


The code
-------------

The code is currently at:
http://git.hellug.gr/?p=xrg/openobject-server;a=shortlog;h=refs/heads/new-
dispatch
http://git.hellug.gr/?p=xrg/openobject-client-
kde;a=shortlog;h=refs/heads/shower-xmlrpc2

Note some testing code for the protocol at:
http://git.hellug.gr/?p=xrg/openerp;a=shortlog;h=refs/heads/tests-52

(look for the tests/http_client.py)