# How our users exploited concurrency and how we fixed it

DevFeed: [How our users exploited concurrency and how we fixed it](<https://devfeed.tech/articles/how-our-users-exploited-concurrency-and-how-we-fixed-it-40612.md>)

Original publisher: [Read original article](<https://eviltrout.com/blog/2013-01-10-exploiting-concurrency/>)

Published: 2013-01-10T00:00:00Z

Content type: article

Language: en

Sources: [Robin Ward](<https://devfeed.tech/sources/robin-ward.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Exploit](<https://devfeed.tech/topics/exploit.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Database](<https://devfeed.tech/topics/database.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [database](<https://devfeed.tech/tags/database.md>), [exploit](<https://devfeed.tech/tags/exploit.md>), [rails](<https://devfeed.tech/tags/rails.md>)

## AI overview

The article explains how a concurrency flaw in a Rails game allowed players to receive rewards multiple times by submitting requests rapidly. It traces the issue to simultaneous requests reading the same database values before an update was applied.

## Source excerpt

A story of a game exploit Once upon a time I developed a somewhat popular web game called Forumwarz. At its peak, we were serving about 6 million dynamic requests a day off a single quad-core server. Forumwarz limits how many turns a player can take in a day. We designed it this way so that the competitive aspect of the game wasn't simply a contest of who had the most time available to play. Players had to choose their targets wisely.