Why I built it
Demoing SiteProbe is awkward. You can't point it at a live customer site in a pitch. Services like httpbin don't return different responses based on request profile — they'll cheerfully echo whatever you send. There's no way to show the core feature (detect profile-dependent divergence) without a target that actually has profile-dependent behavior.
How it works
Build a multi-page mock site with a rule engine. Each rule inspects the incoming request (headers, IP, user agent, rate, cookies) and returns a chosen status code — 200, 403, 429, 503. Load a preset scenario JSON and instantly get "this site aggressively blocks bots," "this site rate-limits too tightly," or "this site fingerprints on missing Accept-Language."
Under the hood
- Rule engine (
rules/engine.py,rules/evaluators.py,rules/types.py) inspects each request against the active scenario. - Stateless — no database. Rules, request logs, and rate counters live in memory.
- Scenario swaps, rule toggles, and request-log inspection happen through an internal interface (not exposed in the public demo).
- Preset scenarios ship in-repo:
aggressive_bot_detection,strict_rate_limiting,overzealous_fraud_rules,header_fingerprinting,combo_realistic,permissive.
Where it stands
A tight-scope companion to SiteProbe, designed to stay stateless and use no database.