Invision Community 4: SEO, prepare for v5 and dormant account notifications Matt November 11, 2024Nov 11
Posted August 19, 200816 yr 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.
August 19, 200816 yr I want this for threads too, it's annoying when you accidently post multiple threads (and posts) +265342654
August 20, 200816 yr 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.
August 20, 200816 yr +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.
August 20, 200816 yr 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.
August 21, 200816 yr 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.
August 21, 200816 yr I think, if you are so worried about double topics, instead of merging, perhaps add in/use a flood filter. ;)
August 21, 200816 yr 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... ^^;;;
August 23, 200816 yr 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.
August 25, 200816 yr 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.
August 25, 200816 yr 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.
August 25, 200816 yr 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
August 25, 200816 yr 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.
August 25, 200816 yr Why don't you come to the dark side and send it with AJAX. You know you should :ph34r:
August 25, 200816 yr 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.
August 25, 200816 yr Well it was for attracting those "AJAX Fast Reply" guys I know it wouldn't :ermm: Or, are you one of 'em :ph34r: :P
August 26, 200816 yr 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.
Archived
This topic is now archived and is closed to further replies.