Thread

The “Deny Duplicate Data” feature in the Admin → Security and Privacy → Security and Session Preferences has me puzzled with regards to its usefulness (especially given that it’s a defulat setting). In the docs this feature is defined as follows:

The “Deny Duplicate Data” feature prevents a comment from being accepted if an identical one already exists in your database. A malicious person can’t submit the same information more than once.

This works exactly as advertised, with one big flaw: it affects all users–-not just the malicious ones. If user 1 and user 2 submit an identical comment (e.g. “+1”), user 2 will get the following error when “Deny Duplicate Data” is enabled (assuming user 2 submitted it after user 1):

Unable to receive your comment at this time.

My Question is, how is this useful / practical in any scenario? More pointedly, what about a typical scenario with non-logged in users posting to a blog? According to both the docs and my understanding of the following function, “Deny Duplicate Data” only checks the comment field and does so against every other comment posted prior to the submission. Here’s the function in the Comment module at line 2268:

/** ----------------------------------------
  /**  Do we allow duplicate data?
  /** ----------------------------------------*/
  if ($this->EE->config->item('deny_duplicate_data') == 'y')
  {
   if ($this->EE->session->userdata['group_id'] != 1)
   {
    $this->EE->db->where('comment', $_POST['comment']);
    $result = $this->EE->db->count_all_results('comments');

    if ($result > 0)
    {
     return $this->EE->output->show_user_error('submission', $this->EE->lang->line('cmt_duplicate_comment_warning'));
    }
   }
  }

I’m not sure how (conceptually speaking), but I’m certain this function can be put to better use for catching malicious duplicate comments. Perhaps it could incorporate date (comment_date), IP address (ip_address) and the entry (entry_id). What do you think? Is this feature request worthy?

1) Good catch.

2) Yes, I believe you’re reading that snippet of code correctly

3) That said, I’m no PHP expert. None the less it might be possible to extend the class / method and “fix” this problem without hurting anything else.

That’s all I got for ya for now 😊

I think it’s definitely worth making the feature request. I don’t know if this would be top of the list for EllisLab. 😊

If it’s a problem for your site (or any site you’re building) you should just disable it and then use other means to try to capture spam comments. I like Low NoSpam.

Thanks for the feedback. It’s nice to finally see some responses to my posts 😉

@Ryan: I definitely agree this is not at the top of list. It’s certainly not on the top of mine either. I simply find it odd that a crippling feature such as this is enabled by default and think there’s a better way to handle this issue. If anyone else has some thoughts, extending the class should be pretty trivial as an immediate solution.

On the note of spam, that’s not a problem for us. Not yet, anyway. There’s a brand new, fully redesigned EE build of our site just around the corner. Hence, my heightened activity in the forums lately.

Thanks again for chiming in!

Actually, relative to the fix, I think it could be a top priority. That is, it wouldn’t take much to fix and it is kinda a nasty “bug” to have.