Log the comment contents

[maltfield]

This ticket is a request to update dam-spam's Logs section to display the comment's content.

• example.com/wp-admin/admin.php?page=dam-spam-logs

Why?

Currently it's very hard for dam-spam users to view the performance (eg check for false-positives) of dam-spam's moderation.

We can view some statistics about comments that were automatically marked as spam (by default only the most-recent 25 comments). We can view metadata about the comment, eg:

1. date/time
2. email
3. ip
4. name
5. script
6. reason

But, surprisingly, we can't view the actual comment that the user left -- which makes it almost impossible to determine if the event was a false-positive or not.

Solution

Add a column to the Logs section's table that lets us view the content of the comment (either directly in the table or by clicking a link in the row).

[maltfield]

Note: another potential solution to this would be to just update dam-spam to use the built-in Wordpress Comment Moderation Queues, which is probably better long-term

• Use Wordpress Comment Moderation Folders (Spam, Trash, etc) #43

[webguyio]

This is something I've thought about before and it's a great idea on paper, but it wouldn't be trivial to add, and honestly, it makes me nervous security, privacy, performance, and storage wise. Because it would need to log the contents of all form submissions, not just comments.

My instinct would be to keep it limited to say the first 100 characters of the post content, which would be enough to distinguish whether it's a false positive or genuinely spam, but then if it's not spam, it would be frustrating to not be able to approve and publish the full content.

You've identified a glaring flaw in how the plugin has always worked; the issue is coming up with an elegant solution.

I'll think on it.

[maltfield]

My instinct would be to keep it limited to say the first 100 characters

I don't really see this as an issue for most websites.

But for big sites, adding an option for something like that sounds reasonable.

Maybe pass it through an html sanitizer first, and truncate its contents to the first 512 bytes or something (by default). But let 512 be a user-configureable option. Let them type the number of bytes to truncate-to -- where 0 means don't truncate the contents

[maltfield]

Likewise, it would be nice if the "number of logs entries to keep" was:

1. Not a dropdown menu, but an input field where a user could type a number (where 0 = keep all entries indefinitely)
2. Specified the units (100 WHATs = Log Entries)

...but that might be a separate ticket

[webguyio]

Definitely, if this happens, the security would need to be thought about very carefully. Even if it's sanitized/escaped aggressively, I'd still rather not store and display form content at all. It's a dangerous door to open security and privacy wise.

[maltfield]

I don't think sanitation is a hard problem to solve.

You could literally just remove any characters other than [A-Za-z0-9] and it'll be completely safe.

[webguyio]

Yes and no.

We'd sanitize with sanitize_textarea_field() and then display it with esc_html().

That part is easy enough. It's the mere fact of opening another door for potential exploit at all that's the problem. It's more code to maintain and scrutinize, another point of failure should some future contributor accidentally forget to check something, etc.

Simplicity is the friend of security and complexity is its very worst enemy.

It's a great idea and worth further consideration, just sticking a pin in it for the moment.