Bune practici

Cele mai multe probleme cu o unealtă ca asta nu vin din bug-uri, ci din capabilități pornite prea devreme pe „blochează" sau din protecții care s-au oprit fără să anunțe pe nimeni. Pagina asta e despre cum eviți amândouă.

#Lansează în „doar observ" întâi

Fiecare capabilitate poate bloca, din greșeală, trafic legitim — și afli asta doar pe traficul tău real:

• Detectarea de boți blochează integratori legitimi pe rute de API (biblioteci HTTP, scripturi ale clienților).
• Blocarea de atacuri poate reacționa la text scris de un om, pe editoare sau formulare de suport.
• Validarea de email cu „blochează providerii gratuiți" respinge gmail — adică majoritatea utilizatorilor reali.
• Challenge-ul blochează clienții care încă nu trimit antetul (pagini din cache, aplicații mobile neactualizate).

În „doar observ", toate astea sunt doar rânduri într-un grafic. În „blochează", sunt erorile utilizatorilor tăi.

Procedura:

1. Pornește totul pe „doar observ", din dashboard, pe trafic real.
2. Lasă să treacă cel puțin câteva zile.
3. Uită-te în dashboard ce ar fi fost blocat și verifică că nu e trafic bun.
4. Treci pe „blochează" o singură capabilitate — cea cu cele mai puține blocări greșite.
5. Repetă. Nu comuta două deodată, ca să știi care a produs o eventuală reclamație.

Toți pașii se fac din dashboard, cu un click — fără redeploy.

#Ce montezi pe fiecare tip de rută

Fiindcă toate se reglează din dashboard, „ce montezi" înseamnă de fapt „ce pornești" — codul e același peste tot.

#Alege corect după ce numeri rate limit-ul

Implicit, limita numără pe adresă IP. Pe rutele unde utilizatorul e deja logat, e cheia greșită: colegi din aceeași rețea (birou, școală, operator mobil) apar sub același IP și se blochează reciproc. Numără pe utilizator:

await security.protect(request, { fingerprint: `user:${session.userId}` });

Pentru API-uri, tiparul bun e două limite paralele: una pe IP, largă (oprește abuzul brut), și una pe utilizator/cheie, mai strânsă (izolează un client zgomotos).

#Ce se întâmplă dacă serviciul e indisponibil

Capabilitățile care au nevoie de serviciul Hazeloft (rate limit, verificare de domeniu) sunt „fail-open": dacă serviciul e momentan indisponibil, cererea trece. E alegerea corectă — nu vrem ca o problemă de rețea la noi să-ți dărâme înregistrările sau login-ul.

Consecința practică: dacă vrei să știi când o protecție n-a rulat, urmărește în dashboard capabilitățile care apar ca „nerulate" sau cu erori — nu doar blocările. O limită care s-a oprit tăcut arată exact ca o limită care nu e atinsă de nimeni.

#Depanare

Challenge-ul blochează pe toată lumea. Cel mai probabil, clienții tăi încă nu trimit antetul de challenge. Ține-l pe „doar observ" până în dashboard vezi că nu mai apar cereri „fără antet", apoi treci pe „blochează".

Utilizatori reali blocați la înregistrare. Uită-te în logurile de blocări la motivul din coloana de detaliu: cel mai des e validarea de nume (pe nume scurte sau non-latine) sau validarea de email cu providerii gratuiți blocați. Ambele se relaxează din dashboard.

Rate limit-ul pare că nu funcționează. Verifică: (1) fiecare limită are un name distinct (altfel se amestecă); (2) numeri pe cheia potrivită — pe IP sau pe utilizator; (3) în dashboard capabilitatea nu apare ca „nerulată".

#Înainte să treci pe „blochează"

• Fiecare capabilitate a rulat pe „doar observ" câteva zile, pe trafic real
• Ai verificat că nu prinde trafic legitim
• Ai o alertă pe erori / capabilități nerulate
• Fiecare limită are numele ei
• Rutele de API nu au detectare de boți sau challenge montate
• Comuți o singură capabilitate odată