Un fapt util: poți face ca Managed Challenge din Cloudflare să pornească pe /search doar când interogarea conține un ampersand. Dacă ai căutare cu fațete sau endpoint-uri costisitoare, astfel nu mai blochezi căutările simple '?q=term', dar încetinești crawlerele care folosesc mai mulți parametri.
Expresia regulii:
(http.request.uri.path wildcard r"/search/*" and http.request.uri.query contains "&")
De ce funcționează: '&' înseamnă de obicei parametri multipli (fațete, paginare, filtre). Multe crawlere enumeră combinații; căutările umane simple trimit adesea un singur 'q'. E un heuritic ieftin și specific care reduce fricțiunea pentru utilizatorii normali.
Compromisuri și limite:
- E un heuritic, nu securitate. Boții pot evita multiplii parametri sau își pot rări cererile.
- Unii utilizatori legitimi vor avea mai mulți parametri (de ex., sortare, pagină). Vor primi challenge—posibil acceptabil dacă vrei să protejezi interogările scumpe, dar măsoară impactul.
- Aplică-l doar unde are sens (de ex., pe calea de căutare) și păstrează rate limiting și loguri.
Notă interesantă: autorul a încercat Cloudflare MCP cu Claude Code pentru a edita regula și a dat de limitări; soluția practică a fost fallback pe Cloudflare API. Concluzia mea: acoperirea MCP pentru suprafețe de administrare specifice vendorilor e încă inconsistentă. Ține la îndemână playbook-ul de API și proiectează automatizări care pot coborî la apeluri API brute când unelte intermediare nu pot.
Ce aș urmări:
- Rata de challenge vs. căutări reușite în analytics după rollout.
- Dacă crawlerele se adaptează (de ex., crawling cu un singur parametru), adaugă straturi: reputație pe header, allowlist pe metodă/cale și rate limiting mai fin.
Concluzie practică: această expresie e un mod rapid de a nu deranja căutările normale, dar de a verifica pe cele costisitoare. Merită citit originalul pentru detalii și nuanțe.