Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Generic honeypot utilities for use in django projects.

tag: 0.1.0

Fetching latest commit…

Cannot retrieve the latest commit at this time



Django application that provides utilities for preventing automated form spam.

Provides template tags, view decorators, and middleware to add and verify honeypot fields to forms.

django-honeypot is a project of Sunlight Labs (c) 2009. Written by James Turk <>



python >= 2.4

django >= 1.0


To install run

python install

which will install the application into the site-packages directory.


Be sure to add honeypot to INSTALLED_APPS in

You will almost always need to define HONEYPOT_FIELD_NAME which is the name to use for the honeypot field. Some sophisticated bots will attempt to avoid fields named honeypot, so it may be wise to name the field something slightly more realistic such as "phonenumber" or "body2".

HONEYPOT_VALUE is an option that you can specify to populate the honeypot field, by default the honeypot field will be empty and any text entered into it will result in a failed POST. HONEYPOT_VALUE can be a string or a callable that takes no arguments.

HONEYPOT_VERIFIER is an advanced option that you can specify to validate the honeypot. The default verifier ensures that the contents of the honeypot field matches HONEYPOT_VALUE. Using a combination of a callable for HONEYPOT_VALUE and HONEYPOT_VERIFIER it is possible to implement a more advanced technique such as using timestamps.

Adding honeypot fields to specific forms and views

It is possible to add honeypot fields to specific forms and ensure that specific views check for a valid honeypotin request.POST. This can be accomplished by using the render_honeypot_field template tag:

At the top of a template file include the line:

{% load honeypot %}

And then within any form including the tag:

{% render_honeypot_field "field_name" %}

will render a honeypot field named "field_name" that is hidden by default. The name of the honeypot field will default to HONEYPOT_FIELD_NAME if one is not provided.

To ensure that the honeypot field is both present and correct you will need to use check_honeypot decorator from honeypot.decorators:

from honeypot.decorators import check_honeypot

def post_comment(request):

def other_post_view(request):

This decorator will ensure that a field exists in request.POST that is named 'field_name'. @check_honeypot without arguments will use the default HONEYPOT_FIELD_NAME.

Adding honeypot fields site-wide

Sometimes it is desirable to add honeypots to all forms site-wide. This is particularly useful when dealing with apps that render their own forms. For this purpose three middlewares are provided, similar in functionality to django's own CSRF middleware.

All of these middleware live in honeypot.middleware.

HoneypotResponseMiddleware analyzes the output of all responses and rewrites any forms that use method="POST" to contain a honeypot field, just as if they had started with {% render_honeypot_field %}. Borrowing heavily from django.contrib.csrf.middleware.CsrfResponseMiddleware this middleware only rewrites responses with Content-Type text/html or application/xhtml+xml.

HoneypotViewMiddleware ensures that for all incoming POST requests to views request.POST contains a valid honeypot field as defined by the HONEYPOT_FIELD_NAME, HONEYPOT_VALUE, and HONEYPOT_VERIFIER settings. The result is the same as if every view in your project were decorated with @check_honeypot.

HoneypotMiddleware is a combined middleware that applies both HoneypotResponseMiddleware and HoneypotViewMiddleware, this is the easiest way to get honeypot fields site-wide and can be used in many if not most cases.

Something went wrong with that request. Please try again.