--- title: "Why a Control Panel Logged Every 302 Redirect Against the User" canonical: https://dxdev.com/everyday-ai/system-mistook-ordinary-clicks-for-an-attack/ datePublished: 2026-04-14 --- Four menu clicks in the control panel were being counted as eight to twelve requests by the site's own speed check. Every [302 redirect](/blog/rate-limiter-banned-power-users-302-200-redirects/) 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. ## Looking for a lock that did not exist We opened the ticket expecting a simple setting problem. A safety check is meant to spot someone pounding on the site with too many requests, and 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. Our first move was the wrong one. We took it for an ordinary address block, the kind you lift by removing a number from a list, so we went looking at the network firewall. The ticket gave the address as one long decimal number, and our first decoding of it was wrong, so we 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. ## What the record showed We pulled up the record for the account, checked the times, and did the math. 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 became eight or twelve recorded requests. The safety check was not counting menu choices. It was counting every stop along the way, and it could not tell a person moving normally through the control panel from someone outside trying to overwhelm the site. To the rule, a hit was a hit. The mistake had been sitting there because the rule was older than the current way the control panel moves people around. Over time the routes got more involved, and the old rule stayed exactly the same. A customer finally ran into the edge of it, and had to spend their patience reporting a problem that should not have been theirs to find. ## The obvious fix that would not have worked At first we 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 us toward the obvious answer: raise the number. That answer was wrong. 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 would still produce 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. It took time to untangle, and meanwhile the customer was stuck in a control panel that kept treating normal work as suspicious. ## What we changed Once we 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 no longer just sit there after the rule changed. A speed flag set during a short burst of ordinary navigation could now 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. Once 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. We are 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, which is no proof 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 here is the ratio. Raising the ceiling would have left a 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. ## What to ask your team or vendor Ask whether the site's [rate limits](/blog/upstream-filtering-outsized-metric-impact/) count what a person chose or every request the system makes on their behalf, redirects included. A limit that overcounts four menu clicks as eight to twelve requests will lock out ordinary users, and raising the ceiling does not fix the count. Check any older safety rule against how people use the product today.