---
title: "A Rate Limiter Kept Locking Out a Real Admin, Counting Our Own Redirects as an Attack"
canonical: https://dxdev.com/blog/2026-04-10_system-mistook-ordinary-clicks-for-an-attack/
datePublished: 2026-04-10
---
Four menu clicks in the control panel were being counted as eight to twelve requests by the site's own speed check, because every 302 redirect along the way was logged as if the person had chosen it. That inflated count pushed an ordinary user over the limit a few clicks into normal work, and the site threw them out of the control panel even though nothing outside was blocking them.

I opened the ticket expecting a simple setting problem. There was a safety check meant to spot someone pounding on the site with too many requests. It had marked this person as clicking too fast. That sounds reasonable until you remember what the person was doing: moving through menus that we put there.

My first move was the wrong one. I took it for an ordinary address block, the kind you lift by removing a number from a list, so I went looking at the network firewall. The ticket gave the address as one long decimal number and my first decoding of it was wrong, so I checked the firewall for both possible readings. The address was on no list. Every request from it was getting through to the server and then being sent to an error page from inside the site itself. Nothing was blocking this person. Something in the site was pushing them out, and I had been looking for a lock that did not exist.

I pulled up the record for the account, checked the times, and did the math. The clicks were quick, but not in the way an attack is quick. There were about 8 to 12 requests in a short stretch. That can sound like a lot if you picture somebody hitting a button over and over. It looks different when you picture someone opening a menu, choosing a page, reading it, then choosing another.

The clue was in what happened between the click and the page. The control panel used a **302 redirect**, which is just a short detour before the browser reaches the page it was trying to open. One click could create more than one logged request in less than half a second. Four menu clicks could become eight or twelve recorded requests.

The safety check was not counting menu choices. It was counting every stop along the way. It could not tell the difference between a person moving normally through the control panel and someone outside trying to overwhelm the site. To the rule, a hit was a hit.

That mistake had been sitting there quietly because the rule was older than the current way the control panel moves people around. Over time, the routes got more involved. The old rule stayed exactly the same. A customer finally ran into the edge of it, then had to spend their patience reporting a problem that should not have been theirs to find.

At first, I looked at the rule itself with Claude. The first read came back clean. The steps made sense as written, and the limit matched the documented intent. Claude did note that the speed limit might be too tight. That sent me toward the obvious answer: raise the number.

It was the wrong answer. Raising the number would have given a heavy user a little more room, but it would not have fixed the count. Every ordinary menu click still produced several entries. It would be like fixing a grocery receipt that charged you twice for every loaf of bread by raising the amount you are allowed to spend. The total would still be wrong. This took time to untangle, and it left the customer stuck in a control panel that kept treating normal work as suspicious.

Once I understood that, the fix had four parts. First, we added a way to sort requests before counting them. The control panel's own detours went in one group. Requests that looked like outside probing went in another. The normal navigation steps still appeared in the record, but they stopped adding to the counter that could block an account.

Second, old flags could not just sit there after the rule changed. A speed flag set during a short burst of ordinary navigation could clear itself if the account stayed quiet for a set time afterward. That kept someone from remaining blocked until a person happened to notice.

Third, the daily limit went up. By itself, that would only have hidden the problem for longer. After the count began separating the right things, it became a sensible bit of extra room for people who use the control panel heavily.

There was one important limit to the fix. The sorting step relies on information that comes with the request, and that information ultimately comes from the visitor's browser. It can reduce bad blocks. It cannot prove what a person's intent was. That is why the safety check still needs a human judgment behind it, especially when account access is on the line.

I am left with a broader question. How many old safety rules are still judging today's work by yesterday's picture of how people use a product? The first report was the first time this problem became visible, not proof that it had never happened before. A person who did not report it might have simply thought the site was flaky and moved on.

The number to trust in this story is not the limit, it is the ratio: four menu clicks becoming eight to twelve logged requests, because each 302 detour was counted as if the person had chosen it. Raising the ceiling would have left that two-to-three-times overcount in place, and the next heavy user would have reached the edge of it just as this one did. The fix worked because the counter stopped seeing its own redirects, so a person who clicked four times was finally recorded as having clicked four times.