Adding honeypot to user and post creation. Fixes #1802

[dessalines]

No description provided.

[Nutomic]

Maybe this could be implemented directly in lemmy-ui, without changing anything in the backend?

[dessalines]

It needs a back-end check, because a good bot could bypass any javascript protections:

• https://stackoverflow.com/questions/36227376/better-honeypot-implementation-form-anti-spam
• https://stackoverflow.com/questions/15319942/preventing-bot-form-submission

[Nutomic]

I mean that lemmy-ui could run some server-side js code to perform this check.

[dessalines]

You mean as part of the isomorphic layer? That'd be way too complicated to intercept.

[Nutomic]

Alright. In fact I was thinking it would be nice to move user settings which are specific to lemmy-ui (like theme) out of lemmy, and handle them entirely in lemmy-ui instead. That would mean lemmy-ui gets its own database connection to store those things. It would make changes to settings much easier, and we wouldnt have to worry about backwards compatibility. But of course that would be even more complicated.

[Nutomic]

About this PR, just after merging I'm thinking that its actually not implemented in a good way. First of all, the field is named honeypot, which makes it very easy for a bot to distinguish. It might be better to give it a different name in the API, and just mention in the docs that its for honeypot.

Also, this section from your second link:

The other half of the secret is keeping it. Do not alter the response in any way if the box is checked. Show the same confirmation, thank you, or whatever message or page afterwards. That will prevent the bot from knowing it has been rejected.

So I think that honeypot_check should actually return HTTP 200, and also return a random LoginResponse.

[dessalines]

So I think that honeypot_check should actually return HTTP 200, and also return a random LoginResponse.

I was thinking instead, that we should just ban and mass delete content for any account with those fields filled. Then we won't have to do that manually. But that's something we can add later.

I'm not sure about the field name either... at least on the front end I have them renamed to other things, but you're right any bot doing it through the api might ignore that field name.

[Nutomic]

I was thinking instead, that we should just ban and mass delete content for any account with those fields filled. Then we won't have to do that manually. But that's something we can add later.

With the implementation in this PR, having that field filled means that account creation fails in the first place, so there is no possibility for bots to create accounts (except for old bot accounts that registered before deploying this). So for that to make sense, it would have to actually create the account if honeypot is filled, and add a bot flag. Not sure thats worth the trouble.

[dessalines]

Ah, I meant for the post create honeypot. But yeah we can worry about that later.