===============
django-honeypot
===============
.. image:: https://github.com/jamesturk/django-honeypot/actions/workflows/test.yml/badge.svg
.. image:: https://img.shields.io/pypi/v/django-honeypot.svg
:target: https://pypi.python.org/pypi/django-honeypot
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.
Written by James Turk with contributions by Flavio Curella and Daniel Greenfeld.
Source: https://github.com/jamesturk/django-honeypot/
Requirements
============
* python >= 3.8
* django >= 3.2
Usage
=====
settings.py
-----------
Be sure to add ``honeypot`` to ``INSTALLED_APPS`` in settings.py.
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``:
.. code:: python
from honeypot.decorators import check_honeypot
@check_honeypot(field_name='hp_field_name')
def post_comment(request):
...
@check_honeypot
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 to class-based-views
-------------------------------------------
The same as above for `Adding honeypot fields to specific forms and views`_ but add the decorator to the post method making use of django's `method_decorator <https://docs.djangoproject.com/en/3.2/topics/class-based-views/intro/#decorating-the-class>`_.
.. code:: python
from django.utils.decorators import method_decorator
from honeypot.decorators import check_honeypot
@method_decorator(check_honeypot, name='post')
class MyView(FormView):
...
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. The middleware needs to be listed after ``CommonMiddleware`` because the middleware changes the response. If you list it before ``CommonMiddleware`` then the ``Content-Length`` header won't reflect the changes.
Customizing honeypot display
----------------------------
There are two templates used by django-honeypot that can be used to control various aspects of how the honeypot functionality is presented to the user.
``honeypot/honeypot_field.html`` is used to render the honeypot field. It is given two context variables ``fieldname`` and ``value``, corresponding to ``HONEYPOT_FIELD_NAME`` and ``HONEYPOT_VALUE`` or any overrides in effect (such as a custom field name passed to the template tag).
``honeypot/honeypot_error.html`` is the error page rendered when a bad request is intercepted. It is given the context variable ``fieldname`` representing the name of the honeypot field.
Raw data
{
"_id": null,
"home_page": "https://github.com/jamesturk/django-honeypot/",
"name": "django-honeypot",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.8,<4.0",
"maintainer_email": "",
"keywords": "",
"author": "James Turk",
"author_email": "dev@jamesturk.net",
"download_url": "https://files.pythonhosted.org/packages/26/81/5c1eb38f8acd11c2f393319f2c472895a999572b86b4fbd0cc9767d5456e/django_honeypot-1.1.0.tar.gz",
"platform": null,
"description": "===============\ndjango-honeypot\n===============\n\n.. image:: https://github.com/jamesturk/django-honeypot/actions/workflows/test.yml/badge.svg\n\n.. image:: https://img.shields.io/pypi/v/django-honeypot.svg\n :target: https://pypi.python.org/pypi/django-honeypot\n\nDjango application that provides utilities for preventing automated form spam.\n\nProvides template tags, view decorators, and middleware to add and verify honeypot fields to forms.\n\nWritten by James Turk with contributions by Flavio Curella and Daniel Greenfeld.\n\nSource: https://github.com/jamesturk/django-honeypot/\n\nRequirements\n============\n\n* python >= 3.8\n* django >= 3.2\n\nUsage\n=====\n\nsettings.py\n-----------\n\nBe sure to add ``honeypot`` to ``INSTALLED_APPS`` in settings.py.\n\nYou 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\".\n\n``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.\n\n``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.\n\nAdding honeypot fields to specific forms and views\n--------------------------------------------------\n\nIt 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:\n\nAt the top of a template file include the line::\n\n {% load honeypot %}\n\nAnd then within any form including the tag::\n\n {% render_honeypot_field \"field_name\" %}\n\nwill 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.\n\nTo ensure that the honeypot field is both present and correct you will need to use ``check_honeypot`` decorator from ``honeypot.decorators``:\n\n.. code:: python\n\n from honeypot.decorators import check_honeypot\n\n @check_honeypot(field_name='hp_field_name')\n def post_comment(request):\n ...\n\n @check_honeypot\n def other_post_view(request):\n ...\n\nThis 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``.\n\nAdding honeypot fields to class-based-views\n-------------------------------------------\n\nThe same as above for `Adding honeypot fields to specific forms and views`_ but add the decorator to the post method making use of django's `method_decorator <https://docs.djangoproject.com/en/3.2/topics/class-based-views/intro/#decorating-the-class>`_.\n\n\n.. code:: python\n \n from django.utils.decorators import method_decorator\n from honeypot.decorators import check_honeypot\n \n @method_decorator(check_honeypot, name='post')\n class MyView(FormView):\n ...\n\nAdding honeypot fields site-wide\n--------------------------------\n\nSometimes 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.\n\nAll of these middleware live in ``honeypot.middleware``.\n\n``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.\n\n``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``.\n\n``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. The middleware needs to be listed after ``CommonMiddleware`` because the middleware changes the response. If you list it before ``CommonMiddleware`` then the ``Content-Length`` header won't reflect the changes.\n\nCustomizing honeypot display\n----------------------------\n\nThere are two templates used by django-honeypot that can be used to control various aspects of how the honeypot functionality is presented to the user.\n\n``honeypot/honeypot_field.html`` is used to render the honeypot field. It is given two context variables ``fieldname`` and ``value``, corresponding to ``HONEYPOT_FIELD_NAME`` and ``HONEYPOT_VALUE`` or any overrides in effect (such as a custom field name passed to the template tag).\n\n``honeypot/honeypot_error.html`` is the error page rendered when a bad request is intercepted. It is given the context variable ``fieldname`` representing the name of the honeypot field.\n\n",
"bugtrack_url": null,
"license": "BSD-2-Clause",
"summary": "Django honeypot field utilities",
"version": "1.1.0",
"project_urls": {
"Homepage": "https://github.com/jamesturk/django-honeypot/",
"Repository": "https://github.com/jamesturk/django-honeypot/"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "78f8ffa1439f1ba41f63ef95c7416e6fd11221929235096ffd94f9b33e7dafc3",
"md5": "ff2e15cde47fc375ee87528501c5023a",
"sha256": "3eb5447d8531c9357923372c9f06471f1d952dbce757283951706412d2c3fd5a"
},
"downloads": -1,
"filename": "django_honeypot-1.1.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "ff2e15cde47fc375ee87528501c5023a",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8,<4.0",
"size": 10465,
"upload_time": "2023-12-09T07:29:41",
"upload_time_iso_8601": "2023-12-09T07:29:41.616106Z",
"url": "https://files.pythonhosted.org/packages/78/f8/ffa1439f1ba41f63ef95c7416e6fd11221929235096ffd94f9b33e7dafc3/django_honeypot-1.1.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "26815c1eb38f8acd11c2f393319f2c472895a999572b86b4fbd0cc9767d5456e",
"md5": "1f2cf9d4ebecbd89a35a19de6cb6269e",
"sha256": "0fe4c977f5d3665a96d22b16cf7f63229a2eef3704b7570fcc417611ebf6bbb2"
},
"downloads": -1,
"filename": "django_honeypot-1.1.0.tar.gz",
"has_sig": false,
"md5_digest": "1f2cf9d4ebecbd89a35a19de6cb6269e",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8,<4.0",
"size": 9928,
"upload_time": "2023-12-09T07:29:43",
"upload_time_iso_8601": "2023-12-09T07:29:43.406139Z",
"url": "https://files.pythonhosted.org/packages/26/81/5c1eb38f8acd11c2f393319f2c472895a999572b86b4fbd0cc9767d5456e/django_honeypot-1.1.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-12-09 07:29:43",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "jamesturk",
"github_project": "django-honeypot",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "django-honeypot"
}
JSON
