Mimsy Were the Borogoves

Hacks: Articles about programming in Python, Perl, Swift, BASIC, and whatever else I happen to feel like hacking at.

Remembering Django form submissions when authenticating

Jerry Stratton, January 21, 2008

If you play around with the built-in Django login mechanism, you might notice that it has one very useful feature: if your session ends before you submit a form, it will save your form data while you log in, and it lets you know this so that you don’t panic.

Django does this by saving the actual POST dictionary into the form. It encodes it using a special function that pickles it and turns it into an ASCII representation that can be stored in a form.

If we take the line “return render_to_response("cms/login.html", context)” from the authenticate method on the authenticator object and replace it with “return self.login_form(context)”, we can make a smarter login form.

[toggle code]

  • from django.contrib.admin.views.decorators import _encode_post_data
  • …
  • def login_form(self, context):
    • request = self.request
    • if request.POST and 'post_data' in request.POST:
      • # User has failed login BUT has previously saved post data.
      • post_data = request.POST['post_data']
    • elif request.POST and not 'login_submission' in request.POST:
      • # User's session must have expired; save their post data.
      • post_data = _encode_post_data(request.POST)
    • else:
      • post_data = None
    • context['post_data'] = post_data
    • return render_to_response("cms/login.html", context)

There are three cases to check for here: the person is just logging in; the person is logging in after attempting to submit a form; and the person is logging in after mistyping their username or password after attempting to submit a form. And we need to be able to tell the difference between submitting a form that has data worth keeping, and submitting the login form.

For the latter, I added a hidden “login_submission” field to the form. So the logic is this:

  1. If there is POST data and there is a “post_data” field, keep it.
  2. If there is POST data and there is no “login_submission” field, save the POST data in post_data.
  3. Otherwise, don’t save any POST data.

The _encode_post_data and _decode_post_data functions aren’t documented anywhere; I found them by searching the source code for how Django did it. It isn’t a bad idea to assume that if it isn’t documented, it doesn’t exist: there’s no guarantee that this functionality will remain across upgrades, so you may wish to write your own encode and decode functions. I use their functions because they have some security functionality built in.

Saving the POST data is performed by first encoding the POST dictionary and then adding the encoded POST dictionary to the form’s context before rendering the form template. Django already has an encoding (and decoding) function in django.contrib.admin.views.decorators, as _encode_post_data and _decode_post_data.

So the next step is to update the form template to keep this information:

[toggle code]

  • <form action="{{ action_url }}" method="post">
    • {% if post_data %}
      • <h2>Your session has expired. Please log in again to save your data:</h2>
      • <input type="hidden" name="post_data" value="{{ post_data }}" />
    • {% else %}
      • <h2>Please log in to the test CMS:</h2>
    • {% endif %}
    • <table>
      • {{ form }}
    • </table>
    • <input type="hidden" name="login_submission" value="1" />
    • <input type="submit" value="Log In" />
  • </form>

The form displays a different message if there is POST data being stored in it.

In the form object in the view, we can use _decode_post_data to get the POST dictionary back:

[toggle code]

  • if 'post_data' in self.request.POST:
    • post_data = _decode_post_data(self.request.POST['post_data'])

And from there it can be treated as if it were taken directly from request.POST.

In response to Custom authentication in Django: Decorators can be used to restrict access to any view.