Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Using Up/down 6.x-2.0dev with Radioactivity 6.x-1.2 and VotingAPI 6.x-2.3
Clicking the '+' icon on the voting widget multiple times registers only one vote, but it adds radioactivity over and over, making it possible to cheat the system.
Which of the above modules could be the culprit?
Comments
Comment #1
mathieuhelie CreditAttribution: mathieuhelie commentedI think I have it figured out. Radioactivity hooks into vote insertions of VotingAPI to add energy to nodes. VotingAPI does not actually check if a vote already exists for a user, it simply deletes the old vote and writes in a new one. Hence, every time someone votes on a node, energy builds up even though the vote tally doesn't, the old vote is just deleted.
Any ideas on how to modify Radioactivity with the smallest footprint that would fix this?
Comment #2
mathieuhelie CreditAttribution: mathieuhelie commentedChanging to a code issue.
Comment #3
gregglesI think up/down should prevent voting if a user has already voted.
Comment #4
franzkewd CreditAttribution: franzkewd commentedDitto.
Using Fivestar module as well, a multiple click on a star widget registers only one vote on the node page, but it keeps adding over and over radioactivity database record. This is a critical functionality.
Comment #5
gregglesFrom the perspective of radioactivity we could solve this if a new vote in votingapi were treated as
* Undo current vote
* Do a new vote
I think that change is unlikely to make it into votingapi module :/
So, I guess the code in radioactivity that deals with votingapi should check whether someone has already made this exact vote prior to giving the energy. It's a little trickier to know exactly how to respond when someone changes their fivestar vote from a 5 to a 4 :/ I'm starting to think that the generic radioactivity_votingapi functionality should be removed in favor of functionality that is specific to the widgets so that it can better handle situations like this.
Comment #6
Juan C CreditAttribution: Juan C commented+1 tracking...
Comment #7
onaz CreditAttribution: onaz commented#5,
This is problematic since undoing a single vote is impossible. If I have given an energy of 5 to a node yesterday, how can I know what the leftover energy for the single addition is today? Well, we could save the vote timestamps and count backwards when deleting (assuming the decay formula has not changed).
An easier fix would be preventing changing your vote after the first cron run after vote (after the energy has started to decay).
Comment #8
gregglesOnaz, I think it's OK.
* Yesterday: user votes and node gains 5 points.
* Today: the value of that 5 is now down to 4 (for example).
* Today: User votes again causing: subtraction of 5 points, addition of 5 points. The net effect is zero and the 4 points remain.
Comment #9
jthomasbailey CreditAttribution: jthomasbailey commentedSubscribing - this also makes fivestar radioactivity useless
Comment #10
sirkitree CreditAttribution: sirkitree commentedsubscribing
Comment #11
eaton CreditAttribution: eaton commentedThought I'd poke my head in -- the reason that vote-sets are treated as blind updates has to do more with efficiency than anything else. In previous versions of VotingAPI, every vote had the potential to trigger a full set of CRUD operations. I'm not opposed to it, but it definitely makes it dicier to handle very heavy vote storms.
I don't suppose it would be possible to rely on the recalculation cycle -- I haven't looked at radioactivity's code, but it seems like a bad fit for that operation. Hmmm...
Comment #12
gregglesTo provide another example:
* Yesterday: user votes 5 and node gains 5.
* Today: the value of that 5 is now down to 4 (for example)
* Today: the user votes a 4, their 5 is decremented by 5 to -1, the 4 adds 4 points so it now is worth 3 which is roughly what it should be worth if the user had voted a 4 yesterday.
I think that's still OK.
@eaton, that makes sense. I see two solutions here: 1. the widgets prevent voting if the user already has voted. That only works for simple vote widgets like up/down. 2. The API lets people know the old value in addition to the new value. Obviously that has performance implications, perhaps it should be a setting that something like radioactivity could require?
Comment #13
dmegatool CreditAttribution: dmegatool commentedFor me, adjusting Rules was the solution. I'm using a thumb up/down widget so when someone vote, 1 point is added. If he vote again, I got a rule for a vote delete (checking the vote value) so it does -1 and then the vote +1. If he abuse the thumb down, it does +1 -1...
Comment #14
Sutharsan CreditAttribution: Sutharsan at LimoenGroen commentedIssue triage: Closing issue, the 6.x branch is no longer maintained.
If you believe this issue is closed in error, feel free to re-open.