RPC4Django v0.1.6 Feature Requests

A number of feature requests have come in and I am going to outline what I’m going to try to get done. I hope to put out a release next week (I’ve said that before), but that greatly depends on what features go into it.

Access to HttpRequest

One user submitted feature that seems particularly useful is the ability to access variables and data in the HttpRequest that dispatches the RPC method. For example:

This RPC method will be authenticated, but it cannot tell who the user is for example. It does not have the ability to read the REMOTE_USER variable. This would be particularly useful if the RPC method was submitting data and needed to know who the submitter was. To rectify this situation, I am proposing sending the HttpRequest object as a keyword argument:

Methods that need access can accept all the additional keyword arguments and methods that don’t care can be written as normal and do not need to change.

Work with the cross site request forgery framework

Django has added a new module to protect against cross site request forgery (CSRF). Unfortunately, if a user adds the django.middleware.csrf.CsrfViewMiddleware to their project, it will break RPC4Django. CSRF protection works by ensuring that all GET requests are side-effect free and then adding a little bit of random data (the CSRF token) to every form that submits via POST. The server can then verify that the correct random data was POSTed and this ensures that the form was submitted from your site and not some remote site.

Unfortunately, RPC is usually intended to be used in a cross site fashion. The fix is relatively painless, but requires some adversarial testing to make it work under Django 1.0, Django 1.1 and Django 1.2. The code (views.py) will look something like this:

I need to test it out very thoroughly and on a number of setups, but I think this code should do it.

HTTP access control

Usually the Javascript XmlHttpRequest object is subject to the same origin policy. This is a security measure that ensures that Javascript will only access data from the same domain, protocol and port as the initial request. There have always been hacks to get around this and the browser vendors are finally providing a uniform, secure way around.

Basically, RPC4Django will need to respond to an HTTP OPTIONS request with the header Access-Control-Allow-Origin specifying what domains are allowed to send requests. Both allowing HTTP access control and which domains are allowed will be options in settings.py.

Patches and feature requests

As always, I am happy to accept patches, but this is what I’ll be working on next week. Please let me know if there are any other important features that you would like to see in RPC4Django.

14 thoughts on “RPC4Django v0.1.6 Feature Requests

  1. Can’t wait for the new version!
    Thank you very much for this project. I am part of a group of researchers from Italy that is trying to build a Dynamic Carpooling system for mobile devices using Django + XML-RPC. The possibility to access variables and data in the HttpRequest will be very helpful for us.
    By the way, my project is called Dycapo and we hope that the first fully working prototype will be released in June/July. Your rpc4django is an essential part of the project πŸ™‚

  2. @David and Dene

    Thanks for the info about base64.

    I have indeed another small feature request about introspection searching fro rpc signatures: I have a structure like this in my apps (extract):

    |– __init__.py
    |– admin
    | |– __init__.py
    | |– poi.py
    | -- trip.py
    |-- models
    | |-- __init__.py
    | |-- poi.py
    — trip.py
    |– services
    | |– __init__.py
    | |– poi.py
    | -- trip.pyc
    |-- templates
    |-- urls.py
    — views
    |– __init__.py
    |– poi.py
    |– trip.py
    `– trip.py

    rpc services are under folder services but it seems like they are not found even if I put __all__= [‘services’ …] in main __init__.py

    I coded a quick hack to make it work, but there must be a better solution:

  3. What about marshalling of Django Models, as a new feature?
    When trying to return a custom Django Object, that also contains relations to other objects:

    xmlrpclib.Fault: <Fault 1: ":cannot marshal objects”>

  4. @ale
    I took the liberty of formatting your comment with code tags and such. I hope you don’t mind. I think what you need to do is edit your resources.__init__.py and add lines like:

    Perhaps I am not understanding the issue correctly.

    By the way, the latest code is in SVN but I haven’t gotten a chance to add and test access to the HttpRequest object. I think this is going to make me have to modify SimpleXMLRPCDispatcher class instead of using the one built-in to python.

  5. @David
    I did not try to serialize them using Django serializers. Should I use ‘python’ as format to succesfully return them as xml-rpc entities?

    Regarding the access to HttpRequest object: good luck, I wish I had the time to help you with this. I will surely help to test the feature when it’s ready, as we need it πŸ™‚

    Thank you very much for everything

  6. Hello,

    I’ have another small request, I have some methods where I would like to use a @login_required decorator, I know “login” concept does’t apply well in web services but you’ve got the idea, by default users doesn’t have any permission set but they have the most basic one: they are registered.

    I thing we need an option to specify that a method is only available to “registered users” without the need to specify a particular permission. The login required decorator doesn’t work, and it’s impossible to raise a 403 from withon the view function (it will be catched by the caller).

    We also should have something like @staff_required.

    What if we add two options to the rpc decorator ?

    login_required = boolean (default false)
    staff_requred = boolean (default false)

Comments are closed.