RPC4Django Update October 2009

Posted on October 13, 2009 by David

A user has requested that RPC4Django support HTTP access control. This is the new preferred method where newer browsers are allowed to make cross domain AJAX requests (with specific constraints) without having to resort to hacks and workarounds like dynamic script tags. I also want to work on JSON class hinting, which is not currently supported. I’m shooting to get this going in the next week before I leave for a Mexican vacation. Swine flu has made the Mexican resorts very reasonable.

Weird Issue on Chrome

In addition, I have noticed that the authenticated demo site does not work in Google Chrome. Is anyone else experiencing this? Any idea why? There’s no problem with Chrome on the demo site not running ssl.

Django authentication and mod_wsgi

Posted on October 7, 2009April 11, 2010 by David

While I was setting up the RPC4Django authenticated demo site (user = pass = rpc4django, self signed certificate), I ran into an interesting problem. There is a well documented way to use the Django auth database for HTTP basic authentication with apache/mod_python, but an authentication handler for mod_wsgi was not built into Django. After some investigation, I found the part of the mod_wsgi documentation on Django authentication. However, I was curious why a mod_python authentication handler existed in the Django code line, but no such mod_wsgi handler existed despite the fact that mod_wsgi is now the preferred method of Django production deployment.

A mod_wsgi authentication handler

This investigation led me to Django ticket #10809 which contains a patch for a mod_wsgi authentication handler. I found this interesting and I tried to install it into the demo site. At the time, I hadn’t even implemented the .wsgi authentication script and I was using an Apache htpasswd file in addition to the Django auth database. However, when I attempted to install the mod_wsgi handler, I ran into a number of issues. Firstly, mod_wsgi does not seem to be able to import a python module from the python path. Therefore, the line: WSGIAuthUserScript django.contrib.auth.handlers.modwsgi yields:

Call to fopen() failed for 'django.contrib.auth.handlers.modwsgi'.

1	Call to fopen() failed for 'django.contrib.auth.handlers.modwsgi'.

This led me to believe that mod_wsgi literally opens and reads the WSGIAuthUserScript. The problem with this is that DJANGO_SETTINGS_MODULE is not set before that is called and mod_wsgi does not pass environment variables that are set to the auth script. As per the documentation:

Any configuration defined by SetEnv directives is not passed in the ‘environ’ dictionary because doing so would allow users to override the configuration specified in such a way from a ‘.htaccess’ file. Configuration should as a result be placed into the script file itself.

.
This means that any attempt at a generic mod_wsgi authentication handler is moot since it cannot be configured to connect to the correct project’s auth database.

The solution

The solution is simple and not very gratifying: write an auth script specific for your application. This is what the demo site does now.

httpd.conf:

&lt;Location "/"&gt;
    AuthType Basic
    AuthName "Login Required"
    Require valid-user
    AuthBasicProvider wsgi
    WSGIAuthUserScript  /path/to/auth.wsgi
&lt;/Location&gt;

AuthType Basic

AuthName "Login Required"

Require valid-user

AuthBasicProvider wsgi

WSGIAuthUserScript /path/to/auth.wsgi

</Location>

auth.wsgi:

import os
import sys
os.environ['DJANGO_SETTINGS_MODULE'] = 'example.settings'

from django.contrib.auth.models import User
from django import db

def check_password(environ, user, password):
    """
    Authenticates apache/mod_wsgi against Django's auth database.
    """

    db.reset_queries() 

    kwargs = {'username': user, 'is_active': True} 

    try: 
        # checks that the username is valid
        try: 
            user = User.objects.get(**kwargs) 
        except User.DoesNotExist: 
            return None

        # verifies that the password is valid for the user
        if user.check_password(password): 
            return True
        else: 
            return False
    finally: 
        db.connection.close()

import os

import sys

os.environ['DJANGO_SETTINGS_MODULE'] = 'example.settings'

from django.contrib.auth.models import User

from django import db

def check_password(environ, user, password):

"""

Authenticates apache/mod_wsgi against Django's auth database.

"""

db.reset_queries()

kwargs = {'username': user, 'is_active': True}

try:

# checks that the username is valid

try:

user = User.objects.get(**kwargs)

except User.DoesNotExist:

return None

# verifies that the password is valid for the user

if user.check_password(password):

return True

else:

return False

finally:

db.connection.close()

Update (October 9, 2009)

After some discussion on Django ticket #10809 with the author of mod_wsgi, I submitted a patch that includes a Django mod_wsgi auth handler. Hopefully it gets accepted soon.

RPC4Django 0.1.5 is Available

Posted on October 4, 2009 by David

Go get it!

I finally completed the version of RPC4Django that uses Django’s authentication system. I blogged about authenticated RPC services previously, and in reality the changes weren’t too major. The only thing I haven’t decided on is what to do in the event a user executes a method with insufficient privileges. Currently, RPC4Django returns HTTP status code 403 (Forbidden), but that seems almost restful. Depending on any feedback I receive, I may change that to actually return an RPC fault which is more RPC like.

In addition, I was contacted about RPC4Django and unicode and I decided to do some testing. As far as I can tell, it supports full unicode without any problem. I wrote some unit tests to verify this and to make sure it continues to support unicode in the future.

Changes

Authenticated view that ties in with Django’s auth system
Added unicode unit test cases to verify that RPC4Django supports unicode (it does!)
Added authenticated demo site (user = pass = rpc4django, self signed certificate)
Improved the documentation stylesheet

RPC and Authentication

Posted on September 20, 2009September 21, 2009 by David

I’m working on adding support for authenticated service calls to RPC4Django built on top of Django’s user authentication. While doing this, I took a brief look around at how other projects implemented authentication for XMLRPC or JSONRPC. Without exception, they all implemented it such that the username and password was part of the RPC call like so:

from django.contrib.auth import authenticate

def myAuthenticatedMethod(user, password, otherparams):
    # authenticate user
    user = authenticate(username=user, password=password)
    
    # verify the user is valid and has the appropriate permissions
    # perform method actions

from django.contrib.auth import authenticate

def myAuthenticatedMethod(user, password, otherparams):

# authenticate user

user = authenticate(username=user, password=password)

# verify the user is valid and has the appropriate permissions

# perform method actions

Some of them abstracted the actual username and password checking into a decorator, but in the end, the RPC call had the username and password in the parameters. It seemed bulky and out of place. This led to an analysis about authentication and authorization and what should be handled where. As a little spoiler, I don’t like the idea of sending the username and password in the RPC parameters one bit.

Authentication & Authorization

In applications, authentication is the process that confirms the identity of the user. Usually this takes the form of a login form, HTTP basic authentication, or something similar. Authorization is the process to determine whether the user has sufficient privileges to perform the specified action. This takes the form of permission checks based on the authenticated user. Therefore, authentication must come before authorization.

Fortunately, Django’s user authentication helps with both authentication and authorization. The authenticate method checks a username and password against the set of Django users and gets the user object if everything goes well. Once this user object is retrieved, permissions can be checked using the has_perm method. Django has a pretty easy way to create new permissions based on your application’s logic. Permissions have to be checked at the specific method level since permissions are closely tied to the application logic. I like the idea of abstracting much of it into a decorator though. The only remaining question is: where does the username and password come from?

An Example from the Real World

Why should every RPC method need to be specially written to accept the login credentials and authenticate the user? This makes the method only usable as an RPC method and not useful at all to the rest of the project which is bad for code reuse. Amazon s3, a commercial web service for storing files, is a perfect example of the proper way to authenticate and authorize users. With s3, the login information is contained in the HTTP header in a manner similar to HTTP basic authentication and in this way the request can be rejected earlier based on login credentials before the request even routes to the proper method requested. Permission checking, seeing whether the user is allowed to store new files for example, still needs to be done at the method level but at least the identity of the user is known.

Implementation and Demo

For RPC4Django, I’m proposing that authentication be handled at a higher level — with basic HTTP authentication for example. To illustrate this, I set up an https RPC4Django demo site that requires a username and password (rpc4django/rpc4django). The demo site requires that you accept a self-signed certificate. Using python, it is possible to send authenticated requests like so:

from xmlrpclib import ServerProxy
s = ServerProxy('https://rpc4django:rpc4django@rpcauth.davidfischer.name/')
s.system.listMethods()

from xmlrpclib import ServerProxy

s = ServerProxy('https://rpc4django:rpc4django@rpcauth.davidfischer.name/')

s.system.listMethods()

The next step is to modify RPC4Django to actually be able to specify permissions for specific methods and to actually log in the users. Expect a release this week.

Economic Recovery September 2009

Posted on September 16, 2009 by David

This post isn’t really a comment on the state of the economy. However, for a blog that doesn’t have an insane readership, I’ve gotten two requests to come in for full time Django job interviews in the past week for SoCal area positions. Perhaps this is just a testament that established companies are starting to believe in Django and develop with it. One person had found my blog directly and one person had come through Djangogigs.

David Fischer dot Name

Some Things to Some People