Expanded logging options

[rogofsky]

These changes were made to enable this honeypot to run in our environment:

• Added option to log to an hpfeeds broker
• Added option to limit the DB size (useful for lightweight deployments which log externally)
• Added optional password collection

I notice that the request to collect passwords was rejected in #25. That makes sense for deployments on production websites, but this honeypot is also useful in deployments where there is no live site and it is deployed solely for data collection. In this case, there is no possibility for accidental password entry and collecting passwords is very useful for research. However, this PR sets this option to False by default.

[coveralls]

Coverage decreased (-22.3%) to 68.639% when pulling 59404d1 on rogofsky:develop into 1308e5f on dmpayton:develop.

[shawnngtq]

@rogofsky @coveralls

I would love to see this optional password collection. Any chance this is going to happen? 😁

[dmpayton]

@rogofsky I'm not familiar with hpfeeds, but there are some pretty cool things about this PR.

We previously did collect passwords, but I removed it after myself and a few of my coworkers inadvertently tried logging in to the honeypot with our real passwords in a production environment. The muscle memory of "/admin/" can be hard to get rid of. ;)

But #69 has us talking about a setting to toggle the recording of IP addresses for GDPR/PII reasons. If there are valid cases for recording passwords, I could be convinced to allow the same for them.

This PR also has me thinking about configurable handlers for login attempts, e.g.:

• database store
• send email
• hpfeeds
• ...and whatever else anyone comes up with

Define which handlers you want to use in your settings, along with any handler-specific configuration. It'd be much easier to build and test additional integrations in this code base (or outside of it, if the python paths are used). I can definitely envision this in a django-admin-honeypot 2.0 release.

@shawnngtq There's definitely a chance.