Many Hours to Secure Voting Process: No Hopes

I am trying to secure a voting process on a website. The users moderating on my Q&A webapp idea, have to press On It button to start working on a question. But here is the issue, I could find NO WAY to avoid a user from clicking 2 On It buttons on a mobile app, because the Workflow will not have started to set the variables. I have tried using Custom States so the value is set faster, but still he can click on both bottons in very quick succession before the first workflow runs. How can I avoid this unexpected behavior in a simple way? Please help.

I would like to know if it is possible to set Custom States from the Workflow API because setting DB variables are slow enough to make it insecure.

Set the state of an element on the page when some one votes/clicks to say “voted = yes”. Then just set the clickable buttons to be unclickable whilst this state = yes.
Would that work?

Yes, it would work, but it would not prevent any hacker to inject a “send” instruction directly to the server to bypass the element restriction. Do you get what I mean? Restriction on the element level may not be as secure as restricting on the database, specifically when I will need to avoid “farmers” (users who like to collect points based on extended abuse of online systems/games to gain reputation/exp/credits/money etc.)

As you very well point. Security on client side is not security :slight_smile:

But this has a difficult solution because the DB needs time to update. So I guess you can only think in workaround terms.

What I would probably do is add an on click js event to disable the button the ms it’s tapped and launch the workflow. Then let it do its thing and then enable again the buttons via a js workflow action.

At the start of the button workflow, before any database steps, it can disable the button, preventing casual button spamming.

Then on later steps, instead of creating a vote record, the workflow updates the user table with a timestamp and the vote, perhaps conditional on an expiry timestamp from another table, and have a server process collect the votes from the users based on timestamp. That way, successful spamming hacks will just alter their single vote.

Nice approach @mishav

Also, just remembered the 300ms delay on mobile browsers. I guess OP would also need to disable the delay to avoid firing several workflows in that 300ms window, right?

Provided he doesn’t follow your approach that just changes user’s own vote.

Edit: This most probably is not the issue. As I checked that most mobile browsers do not introduce this delay any more.

Kindly inform me, how I can edit the 300ms delay?

Edit: Disregard my previous message. It’s not up to date.

Yes, I think I will add a new user field in the UserDB but I am thinking of a different way to do it, let me know what you guys think.

Each question has a uniqueID. So I will create a new user field with QID from Question table (called WorkingOnQID), if the QID is not empty, the workflow will proceed, but if it contains QID the workflow will not proceed.

What does this mean? It means that eventhough both On It buttons will be pressed, only the first QID that is saved in the user DB table will have a continued workflow, and the other one will simply not continue.

Ok guys, I proudly announce that the technique I suspected will work is working and I will call it a field race trap.

Click as many buttons as fast as you can, whichever workflow fills a field first (in my case Current User WorkingOnQID), the other workflow will fail based on a Not Empty condition. This way 100% guarantees, there is no spamming possible, because it’s impossible for Bubble to write a value on the same field simultaneously, one has to finish first even if only by a fraction of a second.

1 Like