---
title: "The call was coming from inside the house"
canonical: https://dxdev.com/blog/2026-04-10_the-call-was-coming-from-inside-the-house/
datePublished: 2026-04-10
---
A support ticket came in as a login complaint. An admin on the production app kept getting blocked mid-session. The login itself worked; the block landed a few clicks into the control panel. I pulled the `dbo.IPdata` row for the account: `blackListed = 1`, `speedFlag` set. From the outside it read like the abuse filter doing its job, somebody clicked too fast and got throttled. So I opened `dbo.IPFilterLog` expecting to raise a threshold.

The stored procedure logic checked out. Thresholds matched the documented intent. No SQL bugs, no obviously wrong branch. The natural next move on a legacy filter that looks correct is to assume the threshold is a little tight and nudge the number. I almost made that move. Then I pulled the raw IIS log for the flagged IP and did the math on the timestamps myself instead of trusting the summary.

The admin panel does 302 redirects, a lot of them. Click a menu item, land on a routing page, get bounced to the destination: two HTTP requests, one user action, both from the same host, both inside 500 milliseconds. For someone clicking through the panel at a normal pace, that chain fires over and over, and four menu clicks becomes eight logged hits on the same IP in a few seconds. The filter had no way to tell that apart from a script hammering the login form; every request fed the same counter. Cross the daily count and `blackListed` flips to 1, no human in the loop.

The fix that shipped (hotfix 3.344.14, then a follow-up hotfix 3.344.15 for the write-up) taught the filter to recognize its own traffic:

```
// detect our own internal navigation so the SP can skip speedFlag counting.
if(!fileType) {
  var referer = Clean(Request.ServerVariables("HTTP_REFERER"));
  if(referer) {
    var refMatch = referer.match(/^https?:\/\/([^\/]+)/i);
    var refererHost = (refMatch) ? refMatch[1].toLowerCase() : "";
    var currentHost = Clean(Request.ServerVariables("SERVER_NAME")).toLowerCase();
    if(refererHost && currentHost) {
      var refStripped = refererHost.replace(/^www\./, "");
      var curStripped = currentHost.replace(/^www\./, "");
      if(refStripped == curStripped) {
        fileType = "internal-nav";
      }
    }
  }
}
```

Same-host Referer, tag the hit `internal-nav`, and the SP skips the `speedFlag` increment for that class entirely. It still logs the hit, it just stops feeding the counter that flips account state. Paired with that: a 7-day auto-clear on any blacklist the SP set itself (not a human moderator), and the daily threshold raised from 500 to 1500 as a backstop that only means anything once the counting is honest. Raising the number alone, which is what I almost did, would have bought a little headroom and cost nothing to a determined script; the account that tripped it would just have taken a few more clicks to get flagged again. The Referer header is client-supplied, though, so anything that sends a same-host value rides the same exemption and opts straight out of speedFlag counting; the fix trusts a header an attacker can set, and I haven't closed that gap.

The filter was probably right when whoever wrote it shipped it, against a version of the app with fewer internal redirects. The routing model grew more hops over the years. The filter never got told. And the only reason anyone found out is that a customer called it in, because there is still no alert on `speedFlag` set rates or a dashboard surfacing newly blacklisted accounts. A support ticket is the whole detection layer.

## a second one, the day before

A production event page's mobile banner was collapsing to blank space on iOS Safari, background slideshow image sitting right there in the DOM. Eight commits went into it over about twelve hours on 2026-04-09: five attempts before the one that stuck (a `min-height` class swap, an explicit pixel height for Safari's absolutely-positioned children, two runs at moving elements around), one commit of testing scaffolding to redirect the source file for debugging, then the fix and its ship commit. The early attempts kept treating it as a Safari rendering quirk. Safari was rendering exactly the DOM it was handed.

A responsive reorder rule (`mobileOrder`) was lifting the inner content module out of the banner frame at the mobile breakpoint and dropping it lower on the page, leaving the frame with no child to size itself against. Height 0, background gone. Twelve hours in, commit `17015cefe8` reverted every prior attempt and did two things: moved the whole frame wrapper when its module had `mobileOrder`, background and content together, and fixed a `setBackground()` function that had been reading `entry.target` instead of the element it was actually passed. Net diff: 17 lines added, 28 removed, undoing a morning of accumulated patches, and it landed only after someone finally opened DevTools at the mobile breakpoint and looked at what was in the frame instead of asking why the image wasn't painting.

Neither bug was Claude Code's fault. Pointed at "an attacker tripped the filter" or "Safari is mangling the banner," it optimizes inside that frame for as long as you let it, and both frames were wrong from the start, which meant ruling out the outside needed the same evidence as ruling in a suspect, not just an absence of contrary evidence. I had the IIS log and the DOM inspector both times. I just used them second.

The speedFlag dashboard still doesn't exist. I have not opened that ticket.