Antispam recognises spam, publishes regardless

same happens to me, it publishes everything even though it says in the mail that its supposedly not published.

Anonymous users are allowed to post on my site, anyway I temporarily fixed it in a obviously bad way but it was just too annoying too keep unpublishing and removing comments and someone else will have to look into it better.

I did this on line 1080 in antispam.module :

 // Unpublish the comment, if necessary.
   if ($comment->status == COMMENT_PUBLISHED) {
      antispam_content_publish_operation('comment', $comment, 'unpublish', FALSE);
      //making sure, since the function doesn't for some unknown reason that I haven't been able to figure out
      $comment->status = COMMENT_NOT_PUBLISHED;
      comment_save($comment);
    }

but someone else has to look into it

It looks like the comment_unpublish_action API D7 code is broken (see http://drupal.org/node/1324544 for details)

If this correct, a temporary hack fix until the API is fixed is:

In antispam.module, after "comment_unpublish_action($content, array('cid' => $content->cid));" (line 1992), add the following:

// Moyles - comment_unpublish_action seems broken. Do call by hand for now
db_query('UPDATE {comment} SET status = :status WHERE cid = :cid', array(':status' => COMMENT_NOT_PUBLISHED, ':cid' => $content->cid));

The whole else block should look like:

-- Line 1990
else if ($op == 'unpublish') {
comment_unpublish_action($content, array('cid' => $content->cid));
// Moyles - comment_unpublish_action seems broken. Do call by hand for now
db_query('UPDATE {comment} SET status = :status WHERE cid = :cid', array(':status' => COMMENT_NOT_PUBLISHED, ':cid' => $content->cid));

// Allow modules to respond to the updating of a comment.
module_invoke_all('comment_unpublished', $content);
}

I get the same problem.

Antispam marks the comment as spam but publishes anyway.

Same Problem with v6.x-1.3 :(

Since a module hack is required to get this module to do what users expect (unpublish a spam comment) I am bumping to critical.

I have been granted commit rights to the repo for this module. Please see / test attached patch. I have not tested.

Okay, try this one w/o a syntax error instead.

Tested on my site, set permission for anon to publish comments w/o moderation. Comments that are identified as SPAM are unpublished, where comments that are recognized as not being SPAM are published to the site. Note, that without some other trigger/action or rule there will be no notification of the publication of non-SPAM comments.

Fixed in http://drupalcode.org/project/antispam.git/commit/8f89df2

I'm getting this erroneous behavior with the latest version (at least) for forum topics. The item is marked as spam and the antispam moderation queue shows it as unpublished, however, the node is itself set as published and visible to everyone (even to non-authenticated visitors).

I have also tried to select the spam nodes and unpublish them, with no effect. It looks like a problem with the antispam unpublish feature.

Please open a new issue with exact steps to reproduce, after trying with the dev version.

Fixing a typo.

This (or something similiar) is still an issue (for nodes not comments) in the dev branch. The node is flagged as spam and successfully unpublished but users still have access to it. Simply re-saving the node fixes it (users no longer have access).

I made a patch against the dev branch that calls node_access_acquire_grants() to fix this.

@kyoder thanks for the patch! But I believe as a best practice we try not to re-open closed issues, even if the problem looks similar.

Anyways, I have tried to reproduce and test this, and I can confirm the problem exists. The response comes back as spam, the function antispam_content_publish_operation() is executed, but the node is still accessible.

In my case, I may be facing an additional issue as well, because the environment I'm testing this on has the entitycache module (and a bunch of others) enabled, so I may have some extra issues regarding caching not being fully cleared. In any case, after creating the spam node, I can see that $node->status == 1. Then:
- after drush cc all, the node status goes to 0, but it is still visible to anonymous users
- after executing manually node_access_acquire_grants($node);, the node stops being visible to anonymous users.

Even after applying the patch I don't get better results, and I wonder if the order the access grants are regenerated respect to the caches being cleared is affecting my test scenario. Your patch may work in other scenarios though, I just can't test it on a clean install right now.

In any case, here are some very minor nitpicks that could improve the patch:

1. +++ b/antispam.module
   @@ -2014,10 +2014,13 @@ function antispam_content_publish_operation($content_type, $content, $op, $log_a
   +    $node->status = $op == 'publish' ? 1 : 0;
   

   Wouldn't it be better to use NODE_PUBLISHED and NODE_NOT_PUBLISHED here?

2. +++ b/antispam.module
   @@ -2025,12 +2028,15 @@ function antispam_content_publish_operation($content_type, $content, $op, $log_a
   +    // need to update user access to the node
   

   We should start the sentence by a capital letter and finish it with a period.

I'm setting it back to NW assuming that the patch goes into the right direction but is incomplete, but it would be nice if someone else could test it also and provide feedback.

OK I could finally test this on a clean install.

Steps tested:

- Clean drupal 7.x-dev in standard profile, with this module in 7.x-1.x-dev and the patch from #2379263: AKISMET service is not working with current 7.x DEV applied.
- Set up your AKISMET key
- Create a non-admin user, set authenticated users to be able to create "page" nodes
- Log in with the non-admin user, create a node with some spam words in the body field
- The node is saved and classified as spam. The node is successfully unpublished, and anonymous users cannot access the node. In fact the own author gets an Access Denied if they have no permissions to see unpublished content.

So the conclusion is that there may be other factors specific to custom sites affecting the caches and making this problem appear only in certain scenarios.

Marking then this issue back to fixed, as it was in #11.

If someone can come up with a reproducible scenario for the bug, please open a new ticket for that.