{ "info": { "author": "Maurits van Rees", "author_email": "maurits@vanrees.org", "bugtrack_url": null, "classifiers": [ "Framework :: Plone", "Framework :: Plone :: 3.3", "Framework :: Plone :: 4.0", "Framework :: Plone :: 4.1", "Framework :: Plone :: 4.2", "Framework :: Plone :: 4.3", "Programming Language :: Python", "Programming Language :: Python :: 2.4", "Programming Language :: Python :: 2.6", "Programming Language :: Python :: 2.7" ], "description": ".. contents::\n.. Table of contents\n\n\nIntroduction\n============\n\nThis package gives honeypot protection for forms.\n\n.. image:: https://secure.travis-ci.org/collective/collective.honeypot.png?branch=master\n :target: https://travis-ci.org/#!/collective/collective.honeypot\n\n\nUse cases\n=========\n\nSpammers have found you and are pounding various forms on your\nwebsite. Prime victims are the join form, contact form, sendto form\nand comment form.\n\nMaybe you have some captcha protection in place but spammers have\nfound a way around it. Or you want to detect a spammer before doing a\npossibly time consuming validation.\n\nYou have noticed that some scripts send e-mails or add a comment even\nwhen they receive a ``GET`` instead of a ``POST`` request.\n\nYou do not want to put up any user unfriendly captchas, but do not\nwant to make it easy for spammers either.\n\nOr, rather differently, you wonder if you can temporarily disallow all\n``POST`` requests while you are doing a big migration.\n\n\nIdea\n====\n\nOne anti-spam idea that has found adoption is a honeypot: adding a\nfield that would never be filled in by a human. The reasoning is that\nspammers will likely fill in all fields in a form, for two reasons:\n\n1. The bots do not know which fields are required, so they\n fill everything in, just to be sure.\n\n2. After a successful submission, each field might be shown on the\n website, so they fill all fields to get their message in the face\n of unsuspecting visitors.\n\nThe field should be hidden so it does not distract humans. But:\nmaking the input type hidden could mean that a spammer ignores it and\ndoes not fill it in after all, so we hide it with css instead.\n\nSome spambots seem to know a bit about Plone. They know which fields\nare required on a few forms in a standard Plone website without\ncaptchas, or they even know a way around validation. If we add an\ninvisible field they will simply not use it. So: for a few explicitly\nselected forms we require that the invisible field is in the submitted\nform, although it must be empty.\n\n\nInstallation and usage\n======================\n\nAdd ``collective.honeypot`` to the eggs of your zope instance in your\nbuildout config::\n\n [instance]\n eggs =\n collective.honeypot\n\nIn Plone 3.2 or lower (untested) you need to add it to the zcml option\nas well::\n\n [instance]\n eggs =\n collective.honeypot\n zcml =\n collective.honeypot\n\nRun buildout and start the zope instance.\n\nAt this point it does not do anything yet, except that it logs some\ninfo whenever someone does a ``POST``. You should take some measures to\nmake it actually protect forms. Every form that you want to protect,\nneeds a change. You can do that yourself and/or load the standard\nfixes from ``collective.honeypot``.\n\n``collective.honeypot`` has fixes for a few standard Plone templates.\nIf you want to use them, you need to explicitly enable them. How?\n\n\nActivation on Plone 3\n---------------------\n\nGo to the Add-ons (Extra Products) control panel in your Plone Site\nand activate ``collective.honeypot``.\n\nWhat does this do?\n\n- This adds a few skin layers that override several templates and\n scripts.\n\nTwo notes:\n\n- We add the skin layers after the ``custom`` skin layer, so if you\n have customized a skin script or template that we want to override,\n then you should take over the changes in your customization.\n\n- If you have installed ``quintagroup.plonecomments``, then you need\n to change the order of the skin layers. Go to the Zope Management\n Interface, then to Properties tab of the ``portal_skins`` tool. In\n all skin selections put ``honeypot_quinta`` at the first spot behind\n ``custom``. Specifically, it should be above\n ``honeypot_oldcomments`` and ``quintagroup_plonecomments``.\n\nAlternatively you could add ``z3c.jbot`` to the eggs and load our\n``fixes.zcml`` in an own package (on Plone 3 this is not possible in a\nbuildout config). This used to be the only way, but ``z3c.jbot`` on\nPlone 3 gives problems with some packages. Problems have been noted\nin combination with ``Products.CacheSetup`` and with Plone Go Mobile.\n\n\nActivation on Plone 4\n---------------------\n\nYou have two options: do the same as on Plone 3, or load some extra\n``zcml`` to have the fixes available without needing any actions in\nthe Plone UI. The last one is recommended. It also offers an extra\nfix.\n\nThe best option is to load the extra ``fixes`` dependencies\n(``z3c.jbot`` currently) and loading ``fixes.zcml``. In your Plone 4\nbuildout config::\n\n [instance]\n eggs =\n collective.honeypot[fixes]\n zcml =\n collective.honeypot-fixes\n\nWhat does this do?\n\n- This registers overrides for several templates and scripts (using\n ``z3c.jbot``).\n\n- It adds those templates and scripts to the list of extra protected\n actions. This means that a ``POST`` request to these actions now\n **must** have the honeypot field and it **must** be empty.\n\n\nFixes\n=====\n\nYou need to enable the fixes. See `Installation and usage`_ for how\nto do that.\n\nWell, we always change the ``@@authenticator`` view, even if you do\nnot enable the fixes, but that should not have any adverse effect.\n\nSome scripts in standard Plone happily add a comment or send an e-mail\nwhen you use a ``GET`` request. This package does not agree with that\npolicy and has fixes to require a ``POST`` request.\n\nWhen using ``z3c.jbot``, the package detects which fixes are needed.\nPlone 3 and 4 need other fixes. Some add-ons may or may not be\navailable, so we only load fixes that can be applied, especially for\n``plone.app.discussion`` and ``quintagroup.plonecomments``.\n\nIf you override a script or template in an own skin layer or via some\nzcml, then our fixes may have no effect, so you need to do a fix\nyourself.\n\nSo, what are the actual fixes that this package contains?\n\n- Some forms may get the invisible honeypot field automatically. This\n package registers an override for the ``@@authenticator`` view from\n ``plone.protect`` that is used in several templates for csrf\n protection (cross site request forgery). So any template that\n already uses this, is automatically loading our honeypot field.\n\n- ``plone.app.discussion``:\n\n - Add the honeypot field to the 'add comment' form. This fix is\n only done when you load ``fixes.zcml``.\n\n - The honeypot field is *not* required, because the 'add comment'\n form posts to the context, not to a specific action.\n\n- old comments:\n\n - This is the standard commenting system of Plone 3.3 and 4.0. It\n is still available in newer Plone versions, so we always load\n these fixes.\n\n - Add the honeypot field to the 'add comment' form\n (``discussion_reply_form``).\n\n - Require ``POST`` for the ``discussion_reply`` script.\n\n - Require the honeypot field in the ``discussion_reply`` action.\n Note: we cannot require it in ``discussion_reply_form``, because\n any page that allows adding comments will contain a simple form\n with this action and a single button 'Add Comment' to open the\n real form. That initial form will not have our honeypot field.\n\n- ``quintagroup.plonecomments``:\n\n - This is the only add-on that we add a fix for, because we believe\n it is widely used in Plone 3 and 4.0. The tests have been done\n with ``quintagroup.plonecomments`` version 4.1.9.\n\n - Note that ``quintagroup.plonecomments`` 4.1.9 does not seem to\n work in Plone versions 4.1 and higher, which of course have\n ``plone.app.discussion``. This has nothing to do with\n ``collective.honeypot``. Maybe it works if you uninstall\n ``plone.app.discussion``, but this is not recommended.\n\n - For ``quintagroup.plonecomments`` we have the same fixes as for\n the old comments.\n\n- Plone 4:\n\n - Require ``POST`` for the ``send_feedback_site`` and ``sendto``\n scripts.\n\n - Add the honeypot field to the ``sendto_form`` and ``contact-info``\n forms.\n\n - The register form is automatically protected by our\n ``@@authenticator`` override.\n\n - Require the honeypot field for the above actions and the join\n form, specifically: ``sendto_form``, ``sendto``, ``contact-info``,\n ``send_feedback_site``, ``register``, ``join_form``.\n\n- Plone 3:\n\n - We have the same fixes as for Plone 4.\n\n - We also require the honeypot field on the ``join_form`` action.\n Note that in Plone 4 the ``join_form`` only exists under the name\n ``register``.\n\n - We allow skin scripts and templates to use ``from zExceptions\n import Forbidden``. In Plone 4 this is already allowed. We need\n this to be able to use ``raise Forbidden('Use POST please.')`` in\n form actions.\n\n\nProtecting your own forms\n=========================\n\nIn a form that you want to protect, you must add this::\n\n
\n\nThis is all that is needed to have the basic protection of an\ninvisible field that captures spammers if they fill it in. A\n``Forbidden`` exception is raised in that case.\n\nSome forms may get this invisible field automatically. This package\nregisters an override for the ``@@authenticator`` view from\n``plone.protect`` that is used in several templates for csrf\nprotection (cross site request forgery). So any template that already\nuses this, is automatically loading our honeypot field.\n\nFor extra protection, you can add the page on which the form appears\nto the ``EXTRA_PROTECTED_ACTIONS``. This means that the ``Forbidden``\nexception is also raised if the field is not submitted in the form at\nall. See the Configuration_ section.\n\nNote that it would be nice to accept all posts from authenticated\nusers, but our code is run too early in the Zope process: we cannot\nknow yet if the user is logged in or not.\n\n\nConfiguration\n=============\n\nThere is no configuration that you can do within a Plone Site. That\nwould be too easy to get wrong, possibly even disabling the means to\nundo the damage. Also, with multiple Plone Sites in one Zope instance\nthis would get even trickier. So we chose a different approach.\n\nYou can configure settings via environment variables in the\n``zope.conf`` of your zope instance. For testing you could set an\nenvironment variable in your command shell and start the zope instance\nand it will get picked up. But the usual way would be to do this in\n``buildout.cfg``::\n\n [instance]\n environment-vars =\n HONEYPOT_FIELD pooh\n EXTRA_PROTECTED_ACTIONS discussion_reply join_form sendto_form\n WHITELISTED_ACTIONS jq_reveal_email\n WHITELISTED_START jq_*\n IGNORED_FORM_FIELDS secret_field\n ACCEPTED_LOG_LEVEL info\n SPAMMER_LOG_LEVEL error\n DISALLOW_ALL_POSTS no\n\nGeneral notes:\n\n- None of the options are required. It will work fine without any\n environment variables.\n\n- Values are split on whitespace or comma.\n\n- Any ``@`` character gets automatically replaced by a space, to make\n it easier to reference ``@@some_view`` by simply ``some_view``, as\n we always protect them both.\n\nThese are the supported variables:\n\nHONEYPOT_FIELD\n Name to use as input name of the honeypot field. If you give no\n value here, no honeypot checks are done, so you only get some\n logging. This is obviously not the main goal of this package, but\n it may be useful when you need to do some debugging. If you do\n not list the variable, you get the default value of\n ``protected_1``. In case spammers learn about this package and do\n not fill in the standard name, you can change the name here.\n\nEXTRA_PROTECTED_ACTIONS\n For these form actions the honeypot field is required: the field\n **must** be in the posted request, though it of course still **must**\n be empty. If you add actions here but do not change the forms,\n they become unusable for visitors, which is not what you want. On\n the other hand, if you have a form that you no longer wish to use,\n you can add it here and it will stop functioning. For ``@@view``\n simply use ``view`` and it will match both.\n\nWHITELISTED_ACTIONS\n These form actions are not checked. List here actions that are\n harmless, for example actions that load some data via an AJAX\n call. Generally, actions that change nothing in the database and\n do not send emails are safe to add here. If you add this\n environment variable but leave it empty, you override the\n default and do not whitelist anything. By default we whitelist\n these actions:\n\n - ``at_validate_field`` (inline validation)\n\n - ``atct_edit`` (edit form)\n\n - ``edit`` (edit form)\n\n - ``kssValidateField`` (inline validation)\n\n - ``jq_reveal_email`` (``zest.emailhider``)\n\n - ``z3cform_validate_field`` (inline validation)\n\n\n\nWHITELISTED_START\n Form actions starting with one of these strings are not checked.\n See ``WHITELISTED_ACTIONS`` for more info. If you have lots of\n harmless actions that start with ``jq_`` you can add that string\n to this list. Regular expression are too easy to get wrong, so we\n do not support it.\n\nIGNORED_FORM_FIELDS\n We log information about ``POST`` requests, to allow a system admin to\n go through the log and discover posts that are obviously spam\n attempts but are not caught yet and need extra handling, perhaps\n an extra form that should get protection. This information may\n contain form fields that should be left secret or that are not\n interesting. No matter what you fill in here, we always ignore\n fields that contain the term `password`.\n\nACCEPTED_LOG_LEVEL\n Log level for accepted posts. This accepts standard lower or\n upper case log levels: debug, info, warn, warning, error,\n critical. When an unknown level is used or the setting is empty,\n we fall back to the default: ``INFO``.\n\nSPAMMER_LOG_LEVEL\n Log level for caught spammers. This accepts standard lower or\n upper case log levels: debug, info, warn, warning, error,\n critical. When an unknown level is used or the setting is empty,\n we fall back to the default: ``ERROR``.\n\nDISALLOW_ALL_POSTS\n Set this to ``1``, ``on``, ``true``, or ``yes`` to disallow all\n ``POST`` requests. This may be handy if you want to effectively\n make a Plone Site read-only, for example in preparation of a\n security release or when you are doing a big migration in a new\n zope instance and want to keep the old instance alive for the time\n being. Note that, like the rest of the checks, this only has an\n effect in a Plone (or CMF) site, not in the Zope root.\n\n\nWhen are the checks *not* done?\n===============================\n\nThis package does not check fields on any ``GET`` requests, it actually blocks\nthe ``GET`` requests on selected forms and requires a ``POST`` there. Hence the\nfield checks only work on ``POST`` requests.\n\nIf you have made the ``HONEYPOT_FIELD`` configuration option empty, no\nhoneypot checks are done, so you only get some logging.\n\nIf Zope does any traversal, only the original action is checked. For\nexample:\n\n- A visitor makes a POST request to a ``my_form`` action. The\n honeypot checks are done for that action.\n\n- The ``my_form`` action may be an old-style CMF form controller\n action that calls a validation script ``validate_my_form``. This\n validation script does *not* get honeypot checks.\n\n- After validation, the action may do a traverse to a script\n ``do_action`` that does the real work, like changing the database or\n sending an email. This script does *not* get honeypot checks.\n\nAs an aside, if you have such a setup, you should make sure the\n``do_action`` script calls a validation script too and only accepts\n``POST`` requests. Otherwise a smart spammer can bypass the\n``validate_my_form`` validation script by requesting the ``do_action``\nscript directly. And he can bypass the honeypot checks by using a\n``GET`` request.\n\n\nz3c.form\n========\n\nYou can easily add a honeypot field to a ``z3c.form``. Just add a\n``TextLine`` field to your form ``Interface`` definition, set the\n``widgetFactory`` to the widget that ``collective.honeypot`` supplies,\nand make it hidden. Something like this::\n\n from collective.honeypot.z3cform.widget import HoneypotFieldWidget\n from z3c.form import form, interfaces\n from zope import schema\n from zope.interface import Interface\n\n class IHoneypot(Interface):\n # Keep field title empty so visitors do not see it.\n honeypot = schema.TextLine(title=u\"\", required=False)\n\n class MyForm(form.Form):\n fields = form.field.Fields(IHoneypot)\n\n def update(self):\n self.fields['honeypot'].widgetFactory = HoneypotFieldWidget\n self.fields['honeypot'].mode = interfaces.HIDDEN_MODE\n\nSee ``collective/honeypot/discussion/z3cformextender.py`` for an\nexample of how to extend an existing form, in this case the comment\nform in ``plone.app.discussion``.\n\n\nCompatibility\n=============\n\nThis works on Plone 3 and Plone 4. Specifically, it has been tested\nwith Plone 3.3.6, 4.0.10, 4.1.6, 4.2.7, 4.3.2.\n\nIt does *not* work on Plone 2.5. The zope event that we hook into is\nsimply not fired there.\n\n\nChangelog\n=========\n\n\n1.0.2 (2015-10-01)\n------------------\n\n- Split honeypot_field and authenticator view. When\n `@@authenticator`` is called, return the view without rendering it.\n Fixes AttributeError: 'unicode' object has no attribute 'token', for\n example on PloneFormGen quickedit form.\n [maurits]\n\n- Added Travis badge to readme.\n [maurits]\n\n\n1.0.1 (2015-08-25)\n------------------\n\n- Require POST for ``send_feedback`` script. This script can only be\n used by authenticated users, so there is little danger, but POST is\n still better.\n [maurits]\n\n\n1.0 (2015-08-24)\n----------------\n\n- First official public release.\n\n- Add kssValidateField to the default WHITELIST_ACTIONS to suppress kss inline\n validation being logged on Plone <= 4.2 .\n [fredvd]\n\n\n0.7 (2014-04-18)\n----------------\n\n- Add GenericSetup profile, which adds skin layers with our fixes.\n This is recommended on Plone 3. The reason is that this technique\n does not need ``z3c.jbot``, which can have a few ugly side effects\n in Plone 3: ``Products.CacheSetup`` does not like it and in other\n cases Zope does not even start up.\n [maurits]\n\n\n0.6 (2014-04-17)\n----------------\n\n- Whitelist edit forms by default.\n [maurits]\n\n- Log when we load patches and add extra protected actions.\n [maurits]\n\n\n0.5 (2014-04-16)\n----------------\n\n- Support disallowing all posts.\n [maurits]\n\n- Support checking start strings for white listed actions.\n [maurits]\n\n- Allow configuring log levels.\n [maurits]\n\n- Print less when logging the form.\n [maurits]\n\n\n0.4 (2014-04-15)\n----------------\n\n- Add fixes for ``quintagroup.plonecomments``.\n [maurits]\n\n- Add fixes for Plone 3.\n [maurits]\n\n\n0.3 (2014-03-14)\n----------------\n\n- Remove ``z3c.jbot`` from the default dependencies so the\n last change actually works.\n [maurits]\n\n\n0.2 (2014-03-14)\n----------------\n\n- Make ``z3c.jbot`` an extra dependency of ``collective.honeypot[fixes]``.\n This way, you only get ``z3c.jbot`` when you need it.\n [maurits]\n\n\n0.1 (2014-03-14)\n----------------\n\n- Initial release.\n [maurits]", "description_content_type": null, "docs_url": null, "download_url": "", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/collective/collective.honeypot", "keywords": "honeypot antispam form protection plone", "license": "GPL", "maintainer": "", "maintainer_email": "", "name": "collective.honeypot", "package_url": "https://pypi.org/project/collective.honeypot/", "platform": "UNKNOWN", "project_url": "https://pypi.org/project/collective.honeypot/", "project_urls": { "Homepage": "https://github.com/collective/collective.honeypot" }, "release_url": "https://pypi.org/project/collective.honeypot/1.0.2/", "requires_dist": null, "requires_python": "", "summary": "Anti-spam honeypot for Plone", "version": "1.0.2" }, "last_serial": 1746508, "releases": { "1.0": [ { "comment_text": "", "digests": { "md5": "1dbd7f593504bf41ec473958df71c0f4", "sha256": "00c7f65124b98030f62becaaa4e667965dc0fed0516a0fc9186d9a4e73337876" }, "downloads": -1, "filename": "collective.honeypot-1.0.tar.gz", "has_sig": false, "md5_digest": "1dbd7f593504bf41ec473958df71c0f4", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 62621, "upload_time": "2015-08-24T15:03:02", "url": "https://files.pythonhosted.org/packages/5e/03/39fb4cb0fcca94c16648fcd7a8dce0c41e929df492d8a8bf36d7950d4b5d/collective.honeypot-1.0.tar.gz" } ], "1.0.1": [ { "comment_text": "", "digests": { "md5": "9cc6044d393ec615bf77960174369cf2", "sha256": "445c84a809e5fd431453d2c47ac33e4bd95c7672542a05397dc5c786574f315e" }, "downloads": -1, "filename": "collective.honeypot-1.0.1.tar.gz", "has_sig": false, "md5_digest": "9cc6044d393ec615bf77960174369cf2", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 64890, "upload_time": "2015-08-25T13:30:07", "url": "https://files.pythonhosted.org/packages/35/67/a4917da289ee1674d8443b9ef062f2de77c3f3c7feb620b9c43bc57e709a/collective.honeypot-1.0.1.tar.gz" } ], "1.0.2": [ { "comment_text": "", "digests": { "md5": "46ff806c277886ce651cbe108b6d8520", "sha256": "f1d69232938810ee3ca84cc8bb6f51e234a948c67cff60071caf14b7cc6a3675" }, "downloads": -1, "filename": "collective.honeypot-1.0.2.tar.gz", "has_sig": false, "md5_digest": "46ff806c277886ce651cbe108b6d8520", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 65520, "upload_time": "2015-10-01T03:58:32", "url": "https://files.pythonhosted.org/packages/79/91/338fe09c38ba95f5802c72e501e5067a69652d8dd3b97eb582bf6aabc003/collective.honeypot-1.0.2.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "46ff806c277886ce651cbe108b6d8520", "sha256": "f1d69232938810ee3ca84cc8bb6f51e234a948c67cff60071caf14b7cc6a3675" }, "downloads": -1, "filename": "collective.honeypot-1.0.2.tar.gz", "has_sig": false, "md5_digest": "46ff806c277886ce651cbe108b6d8520", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 65520, "upload_time": "2015-10-01T03:58:32", "url": "https://files.pythonhosted.org/packages/79/91/338fe09c38ba95f5802c72e501e5067a69652d8dd3b97eb582bf6aabc003/collective.honeypot-1.0.2.tar.gz" } ] }