Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
double-posting bug
tayholliday
New
This thread was initially a double-post. Are there known bugs for double-posting?
The forum gave me no confirmation after I clicked on post.
thanks!
- Taylor
Tagged:
0
Comments
It is not a bug, but it is something that does happen every now an then, and there are ways of mitigating it, but its important to note the posting is not transactional, and shouldn't have the sort of overhead unless it is absolutely necessary. So if you do anything at all, it can't cost.
grep is your friend.
@x00, sorry I don't really follow. Are you saying that due to performance requirements, a confirmation for a post can't be sent back to the client?
You can do what you like. People don't expect a confirmation, but if you want want you can do it with a little javascript.
grep is your friend.
Still, this doesn't make any sense to me. Why can't posting be made "transactional"? Is sounds like you're making excuses for what to a layperson would be quite obviously a bug.
Not really smart move Tay, on forum answered by volunteers to try an teach grandma to suck eggs. If I give you a technical answer you can take it or leave it I really don't mind. I have no reason to make excuses, it is not my project.
It can be made transactional, I'm just saying it is not necessary, to further mitigate this issue.
For trigger happy posters you could prevent the button from being clicked twice. There is also pseudo-transactional methods. if you want to put in the effort, put in pull request, maybe they will take you up on it.
If you are actually interested in a technical answer, then the level of data integrity checks used on forums, or the vast majority user generated web content is much lower then when you buy a tangible stock item. Especially if you want a scalable system. However it is perfectly acceptable. Performance and scalability are much bigger concerns to the team.
As it happens it is a bit of red herring, as HTTP requests are treated as separate/unrelated, it is only session cookies that relate these request. You can use a nonce to create a sort of create psuedo-transactional post, which could be timed. However it could still come in before the opportunity for the other to be marked, which is called a collision.
Making it truly transactional you would have lock all posting for that user, until it is deemed completely resolved. Such an overhead would be unacceptable, and could be very annoying for users.
In any even you are unlikely to get much better results then you can get with some interface guards, such as some javascript.
grep is your friend.
Sorry, @x00.
Why can't the server just check for duplicate posts? Reject if the same post comes in a short while after.
It may involve an extra query, and the timing can still be off. One can come in and before it is register, the other. That is the nature of concurrency. If you don't allow currency in both you server an database queries you are slowing thing considerably.
Also what is a duplicated post is open to interpretation.
Like I said things could be done, it is just not a big enough issue to warrant it, or else it would have already happened. You are welcome to open up an issue, but I wouldn't hold out on high priority.
grep is your friend.
Well, if you were to consider posts to be duplicates if they have the content/metadata, then you could just allow both database inserts to happen, you just allow the second to stomp the first. I'm thinking of the database as a key-value store though.
Sorry for "sneaking in", but databases are much more than a key-value store (or, better, they should be; the concept of database got a bit "bastardised" with the advent of the various NoSQL stuff).
My shop | About Me
lol @businessdad I have to tease the relational fan boi ;P
NoSQL FTW!
I think key value stores and cache engines got mixed up with databases granted, but that doesn't mean that many NoSQL solutions aren't proper databases.
It is true that the nature of data handling has changed. Solutions followed the need.
You say database I say bucket. The nature of databases was also stereotyped. You have graph based databases for example.
grep is your friend.