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) _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
