Double post detection

[Luke]

The feature that merged your posts if you were the last poster was nice. Something that would really come in handy though is double post detection. If the previous post contains exactly the same content as the one you're posting, then it simply doesn't make the post and redirects like it does. So if for some reason I accidently double click the button, or my mouse goes on a rampage it doesn't make the same post twice.

A way of doing this without adding an unnecessary query check would be to md5 the post or query array and store it in a cookie or session variable. You can then check against that when a post is made. Also since this is based on your last post made and not the topic's last post, it doesn't matter if someone posts right after your first post.

[Mert]

+1

It should have been added with "post merging in X minutes" feature.

[TrixieTang]

I want this for threads too, it's annoying when you accidently post multiple threads (and posts)

+265342654

[atomicknight]

Good idea, although I wonder about the effectiveness of such a system. It certainly would catch accidental double clicks in some situations, but from experience with writing scripts to prevent such things from happening, severe lag between the client and server causes a race condition and the repeated post usually goes through anyway.

Still, definitely something worth looking into.

[Cool Surfer]

+1

Just check ubuntu official forums, when you enter text in topic title, it finds similar articles already existing, and saves you time that you would spend posting the same query again.

[bfarber]

Good idea, although I wonder about the effectiveness of such a system. It certainly would catch accidental double clicks in some situations, but from experience with writing scripts to prevent such things from happening, severe lag between the client and server causes a race condition and the repeated post usually goes through anyway.

Still, definitely something worth looking into.

This is exactly the problem. As I recall there is, or used to be, this exact detection in place. If you were the last poster in the same topic and the post content is the same, it doesn't save the post. The problem is, when the a post is "double submitted" as being talked about here, it is effectively two separate requests coming through simultaneously. By the time the second request is received and we get that far into the script execution to check, the first one hasn't actually inserted the post yet, so it's not there for the second request to see. Unfortunately, this is one of those issues that's virtually impossible to reliably (in any sort of fashion) trap.

+1

Just check ubuntu official forums, when you enter text in topic title, it finds similar articles already existing, and saves you time that you would spend posting the same query again.

He's talking about something completely different.

[Cool Surfer]

He's talking about something completely different.

Yes I know. But there is no delete option on the post, else would have deleted it.
These r two different things.

[Morrigan]

I think, if you are so worried about double topics, instead of merging, perhaps add in/use a flood filter. ;)

[TrixieTang]

I think, if you are so worried about double topics, instead of merging, perhaps add in/use a flood filter. ;)

Actually, now that I think about it... I tend to be the one who hits the post button too many times... ^^;;;

[atomicknight]

I think, if you are so worried about double topics, instead of merging, perhaps add in/use a flood filter. ;)

Flood filters actually suffer from the same "threading" problem. There's no instantaneous block that prevents the second request from going through, so you can still get two requests past the flood control if they're processed at approximately the same time (i.e. before the database insertion takes place). You can probably attempt to mitigate the situation by using a table using the MEMORY engine, but the fundamental "race problem" still exists.

[bfarber]

Javascript solutions are generally the best idea for this sort of thing. Sure, not everyone can use javascript or what not, but for the vast majority of these the solution would stop the second submission on the browser end, preventing the race condition.

[Morrigan]

By Javascript do you mean when you click on the Post button it turns inactive?

[Luke]

The method I was talking about should be pretty effective, and require zero queries to accomplish, thus no load. What you do is take a collection of data from the post like topic title, the post, the form id, etc... and merge it together into a single string. MD5 that string into a hash and store it in a cookie as the "last post". Before doing any queries in the post routine make that hash and check against the cookie. If they match, skip inserting the post and continue like the post has been inserted.

This is why this method is more effective:

1) You do not have to have any additional queries, like checking the last post.
2) If someone managed to post after your first post, your "double post" will not be posted right after theirs.
3) It's mostly client side, and doesn't have any negative draw backs like Java Script does.

If you wanted to take it even further, you could insert a randomly created hash into the post form as a hidden field and use that as a basis (if you wanted to argue that someone may want to post the same thing twice). This method is almost completely client side, and works without javascript.

The java script method of disabling the button is a bad idea because if for some reason the page times out during post and you hit the back button, the button is still disabled. The hash+cookie method is more transparent.

[bfarber]

You're missing the point Luke. :P You said this happens when you, e.g., double click on the submit button.

A cookie is set in the response to your request. Here's the order of what will happen when you double click a submit button.

Request 1 sent
Request 2 sent
Response 1 received (this is where the cookie would be set)
Response 2 received

The cookie would never be in place to check before Request 2 is sent. So your theory wouldn't work. It may not require any queries or anything...but it wouldn't stop the problem. :P

[Luke]

You're missing the point Luke. :P You said this happens when you, e.g., double click on the submit button.

A cookie is set in the response to your request. Here's the order of what will happen when you double click a submit button.

Request 1 sent

Request 2 sent

Response 1 received (this is where the cookie would be set)

Response 2 received

The cookie would never be in place to check before Request 2 is sent. So your theory wouldn't work. It may not require any queries or anything...but it wouldn't stop the problem. :P

Hmmm... I was under the impression that It would go Request, Response, Request, Response... but the browser hasn't caught up with the entire response. But I do see what you mean.

Rats... well the only other thing I can think of is a unique id that gets inserted into the form.. with posts, I guess it's really not the best solution.

Well... is there anyway to re-enable the button when the page activates? (since on-load doesn't fire on the "back" action). There have been times when the button was disabled when I didn't want it to be and I had to copy and paste my post into a reloaded window.

[Mert]

Why don't you come to the dark side and send it with AJAX. You know you should :ph34r:

[bfarber]

Hmmm... I was under the impression that It would go Request, Response, Request, Response... but the browser hasn't caught up with the entire response. But I do see what you mean.

Rats... well the only other thing I can think of is a unique id that gets inserted into the form.. with posts, I guess it's really not the best solution.

Well... is there anyway to re-enable the button when the page activates? (since on-load doesn't fire on the "back" action). There have been times when the button was disabled when I didn't want it to be and I had to copy and paste my post into a reloaded window.

There's probably a way, but we'd have to look into it. Not a huge priority issue.

Why don't you come to the dark side and send it with AJAX. You know you should :ph34r:

Wouldn't resolve the issue.

[Mert]

Well it was for attracting those "AJAX Fast Reply" guys I know it wouldn't :ermm:

Or, are you one of 'em :ph34r:

:P

[henke37]

Request 1 is recived
Server child 1 is spawned
Sever child 1 loads the php page
Server child 1 grabs a mutex for the session data
Request 2 is recived
Server child 2 is spawned
Sever child 2 loads the php page
Server child 2 grabs a mutex for the session data, but is blocked since it's already claimed
Server child 1 loads the session data, checks for duplicate postings and adds the post
Server child 1 updates the session data and releases the mutex
Server child 1 is done
Server child 2 gets the mutex
Server child 2 loads the session data, checks for duplicate postings and detects the duplicate
Server child 2 is done

Conclusion: get mutexes for the session data (i think php already does that) and duplicate posts is not going to slip past.