After researching and setting up two FormWizards in Django I concluded some things that might be useful to others. Hence this post.

Having userdata available throughout the wizard

I’ve seen some solutions on the net for this but when you handle data from several models over different steps the best way to handle this is using Django’s session framework. In parse_params() in the beginning and end we repectively get/set data and store our data.

def parse_params(self, request, *args, **kwargs):
    current_step = self.determine_step(request, *args, **kwargs)
    form = self.get_form(current_step, request.POST)

    # Pickup the dict from the users session or create a new one
    wizdata = request.session.get('wizdata') or {}

    # Your code goes here. E.g. set a value in the dict
    wizdata['some_key'] = 'Some value'

    # Store the possibly changed dict back in the users session.
    request.session['wizdata'] = wizdata

So whatever you do with the user data, it’s safe, and we can access it in any step throughout the wizardry.

def render_template(self, request, form, previous_fields, step, context=None):
    wizdata = request.session.get('wizdata')

    # Your other code goes here. E.g. a conditional on previously set data.
    if wizdata.get('some_key'):
        # Do something with your data
        wizdata['some_key'] = 'Some other value'

    # And again, simply store the dict in the users session.
    request.session['wizdata'] = wizdata

You can imagine that in the parse_params() and the render_template() method you respectively have the ‘if current_step == ‘ or ‘if step == ‘ statements along the way. All having the wizdata dict available.

This also works in the done() method. Simply get the dict one last time from the user session.

def done(self, request, form_list):
    wizdata = request.session.get('wizdata')

    # Other code here

    # Cleanup
    del request.session['wizdata']

Then, for tidyness, at the end of done() we remove the dict from the user session.

Gotchas

There can be stale data, in the form of our stored dicts, left behind when wizard sessions are not finished by the user. This also is true for the sessions itself. As stated in the The Django docs about sessions you should clean up the sessions from time to time.

Anybody that has improvements, questions or compliments please drop me a line

GrtzG

SELECT id, name FROM myapp_model WHERE owner_id='1' GROUP BY name;

This would have been (easily) possible except for the WHERE clause on ownership that screwed me. Since the SQL statement was that simple I decided to write a bypass function that get’s the data straight from the database. It’s readonly access and I dont do anything more with it then create a list of links. Even more so, from a KISS point of view this code is easier to read back after several months.

And for reusability I turned it in to a function. It takes the model and the distinct field, and for my purpose the needed ownership as parameter:

from django.db import connection

def get_latest_objects(model_name=None, distinct_field=None, user_id=None):
    """ Get lastest distinct selection (as tuples) of a given model
    """
    model_name = model_name.lower()
    query = ("select id,%(distinct_field)s from myapp_%(model_name)s "
                "where owner_id='%(user_id)s' "
                "group by %(distinct_field)s;") % {
                    'model_name': model_name,
                    'distinct_field': distinct_field,
                    'user_id': user_id,
                    }
    cursor = connection.cursor()
    cursor.execute(query)

There’s not much to it, I just hope it helps you to avoid ‘the hard way’. And it helps to keeps your view methods more readable because you dont need anything more then this:

latest_objects = get_latest_objects(model_name='MyModel',
                        distinct_field='name',
                        user_id=request.user.id)

What is returned (latest_objects) is a list of tuples that you can unpack in your templates straight away. Note that there’s no error checking in there, because I know what I’m doing Besides, worst case you get back an empty list and possible errors are caught when you write your tests. You do write those don’t you?

Grtz Gerard.

But since wrongfull data disclosure is absolutely unacceptable I was still afraid that I would miss something somewhere. A nice example I ran into was populating a dropdown list in a form, where all records were visible instead of only those owned by the logged in user.

That got me thinking and eventually I wrote this small but sweet piece of middleware. Further elaboration below the code.

from django.db import connection
import re

"""
QueryScreener is a middleware development tool. This tool helps to avoid
unwanted data disclosure once you go into production.

It monitors queries to the models in your model_list and warns you when queries
are executed that do not contain a ownership where clause. And thus can be a
potential data disclosure hazard.

It requires a owner attribute in your model definition, e.g:

    owner = models.ForeignKey(User, editable=False)

Edit the 'model_list' below for what models should be monitored. And add
QueryScreener to MIDDLEWARE_CLASSES in you settings.py

Note: This can/should only be used while running Django's testserver command
with e.g: ./manage.py runserver 192.168.1.81:8000
"""

class QueryScreener(object):

    model_list = ['myapp_customer', 'myapp_order', 'myapp_product']

    def process_view(self, request, view_func, view_args, view_kwargs):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_view')

    def process_response(self, request, response):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_response')
        return response

def query_parse(self, model_list, caller_process):

    for query in connection.queries:
        for modelname in model_list:
            modelstring = 'FROM `'+modelname

            if re.search(modelstring, query['sql']) and not \
                re.search(r'^SELECT.\(1\).AS', query['sql']):

                reg = re.compile(r'^SELECT.*WHERE.*owner.*(ORDER BY.*)?$',
                                    re.DOTALL)

                if not reg.search(query['sql']):
                    print ('<<< WARNING >>> Query execution without ownership '
                            'clause, called from "' + caller_process + '"')
                    print query['sql']

            if re.search(r'^SELECT.\(1\).AS.`a`.FROM.*WHERE.*$', query['sql']):
                print ('<<< Django Farted >>>')
#                print query['sql']

Update1: The ‘ORDER BY’ in the regex needs to be optional.
Update2: Django does a ‘try update’ in save_base() without owner (seperated the select statement)

The comment in the code above sums up how to get it working. What it does is print a warning and the query in question that does not respect ownership. If enabled while developing just keep track of your console output for:

<<< WARNING >>> Query execution without ownership clause, called from "process_response"

Should you  have suggestion, criticism, or words of admiration then please, do tell me

GrtzG

Today I ‘moved’ the first version of my application from the Django development setup (run via “./manage runserver”) to a lighttpd/fcgi production setup. Been cleaning up code and concluded I wanted the app straight on the ‘/’ or docroot with a simple config like this:

HTTP["host"] == "example.int" {
    fastcgi.server = (
        "/" => (
            "main" => (
                "host" => "192.168.1.2",
                "port" => 8000,
                "check-local" => "disable",
                #"fix-root-scriptname" => "enable",
            )
        ),
    )
}

After a lot of messing around and not getting the aformetioned setup to work I found the ‘PATH_INFO’ problem. The easiest way is to have lighttpd version 1.4.23 running, because then you can enable:

    "fix-root-scriptname" => "enable",

And therewith actually acces your app on “/” instead of “/dd” as shown in the below example under the line with “fastcgi.server (“.

The problem however is that lighttpd version 1.4.23 is not apt-get-able yet and I like my systems clean. So here’s the somewhat cumbersome but functional example that works:

HTTP["host"] == "example.int" {
    fastcgi.server = (
        "/dd" => (
            "main" => (
                "host" => "192.168.1.2",
                "port" => 8000,
                "check-local" => "disable",
            )
        ),
    )

    url.rewrite-once = (
        "^(/.*)$" => "/dd/$1",
    )
}

What happens is that lighttpd passes an incoming request like “/url_to_something” to your fcgi proces, but fcgi is on “/dd/url_to_something”. So with the rewrite rule we make sure the “/dd” prefix is added, other wise it would not be passed to the fcgi handler.

The problem however is that you should modify all your in-app links so they would be prefixed with /dd otherwise you end up with a 404. This can be globally resolved by adding the line below to your Django settings.py

FORCE_SCRIPT_NAME = ""

Django then strips of the “/dd” prefix just before it gets parsed by your django app URL Dispatcher.

So when lighttpd version 1.4.23 is in the debian and/or Ubuntu repository, you apt get it and adjust your setup in 3 places.

Remove the rewrite rule and the “dd” part from your lighttpd host config and disable the FORCE_SCRIPT_NAME in your settings.py. Doing it like this keeps everything running with the least adjustments now and only a little work to be done in the near future.