RPC4Django v0.1.6 Feature Requests

Posted on December 9, 2009April 11, 2010 by David

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:

@rpcmethod(permission='myproject.mypermission')
def testmethod(a, b, c):
    # Do something

@rpcmethod(permission='myproject.mypermission')

def testmethod(a, b, c):

# Do something

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:

@rpcmethod(permission='myproject.mypermission')
def testmethod(a, b, c, **kwargs):
    if 'REMOTE_USER' in kwargs['request'].META:
        user = request.kwargs.META['REMOTE_USER']
        # Do something

@rpcmethod(permission='myproject.mypermission')

def testmethod(a, b, c, **kwargs):

if 'REMOTE_USER' in kwargs['request'].META:

user = request.kwargs.META['REMOTE_USER']

# Do something

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:

try:
    # Django 1.2
    from django.views.decorators.csrf import csrf_exempt
except ImportError:
    try:
        # Django 1.1
        from django.contrib.csrf.middleware import csrf_exempt
    except ImportError:
        # Django 1.0
        csrf_exempt = None

if csrf_exempt is not None:
    csrf_exempt(serve_rpc_request)

try:

# Django 1.2

from django.views.decorators.csrf import csrf_exempt

except ImportError:

try:

# Django 1.1

from django.contrib.csrf.middleware import csrf_exempt

except ImportError:

# Django 1.0

csrf_exempt = None

if csrf_exempt is not None:

csrf_exempt(serve_rpc_request)

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”

bodom_lx says:

December 16, 2009 at 11:36 am

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 🙂
Alessandro Pasotti says:

December 17, 2009 at 6:14 am

Hi,

thanks for the updates,

I just have a small question: is it possible to send binary file attachments with RPC through rpc4django ?

Do I really nead SOAP for that ?
David says:

December 18, 2009 at 6:19 pm

@Alessandro Pasotti
There is a way to do this with XMLRPC and I’m not 100% sure JSONRPC. Essentially, any binary object can be sent as a base64 encoded string. The Python XMLRPC docs have the info. I have not tested it out with RPC4Django, but I’d love to know how it works out!
David says:

December 18, 2009 at 7:43 pm

@bodom_lx
I’m glad to hear it is getting some use!
dene says:

December 18, 2009 at 11:08 pm

@David
Binary objects work for me, at least for a png encoded using xmlrpclib.Binary. New version looking good 🙂

@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):

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:


def register_rpcmethods(self, apps):
  '''
  Scans the installed apps for methods with the rpcmethod decorator
  Adds these methods to the list of methods callable via RPC
  '''

  import types

  for appname in apps:
      # check each app for any rpcmethods
      app = __import__(appname, globals(), locals(), ['*'])
      for obj in dir(app):
        method = getattr(app, obj)
        if callable(method) and \
           getattr(method, 'is_rpcmethod', False):
             # if this method is callable and it has the rpcmethod
             # decorator, add it to the dispatcher
             self.register_method(method, method.external_name)
         elif type(method) == types.ModuleType:
            try:
              self.register_rpcmethods(["%s.%s" % (appname, obj)])
            except:
              pass

def register_rpcmethods(self, apps):

'''

Scans the installed apps for methods with the rpcmethod decorator

Adds these methods to the list of methods callable via RPC

'''

import types

for appname in apps:

# check each app for any rpcmethods

app = __import__(appname, globals(), locals(), ['*'])

for obj in dir(app):

method = getattr(app, obj)

if callable(method) and \

getattr(method, 'is_rpcmethod', False):

# if this method is callable and it has the rpcmethod

# decorator, add it to the dispatcher

self.register_method(method, method.external_name)

elif type(method) == types.ModuleType:

try:

self.register_rpcmethods(["%s.%s" % (appname, obj)])

except:

pass

bodom_lx says:

December 23, 2009 at 7:22 am

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”>
David says:

December 23, 2009 at 3:24 pm

@bodom_lx
How exactly are you marshalling them? Are you serializing them first?
David says:

December 23, 2009 at 3:31 pm

@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:

from services import * from services.poi import *

1
2

from services import *
from services.poi import *

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.
bodom_lx says:

December 24, 2009 at 3:17 am

@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
ale says:

January 19, 2010 at 1:13 am

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)
David says:

January 19, 2010 at 7:08 am

@ale
That sounds very useful. I think I can implement it in 0.1.8.
alekam says:

January 24, 2010 at 7:05 am

Thanks for awesome application!
Did you thing about generating WSDL for rpc4django webservices?
David says:

January 24, 2010 at 10:14 pm

@alekam
Do people actually use WSDL for XMLRPC? I know it’s not exclusively for SOAP, but I thought that was its primary use.

Comments are closed.

David Fischer dot Name

Some Things to Some People

RPC4Django v0.1.6 Feature Requests

Access to HttpRequest

Work with the cross site request forgery framework

HTTP access control

Patches and feature requests

14 thoughts on “RPC4Django v0.1.6 Feature Requests”