# Általános

> A tűzfal főkapcsolója, a tároló, a kéréskorlát és a WooCommerce-szűrők és kosárlinkek botvédelme.

![Az LW Firewall Általános füle](https://hub.hellowp.io/_astro/lw-firewall-general.Djr21oKy_Z2eK9GH.webp)

*Az Általános fül alapértékekkel: bekapcsolt tűzfal, automatikus tároló, 30 kérés 60 másodperc alatt, bekapcsolt WooCommerce-szűrők.* (https://pelda.hu/wp-admin/admin.php?page=lw-firewall#general)

Az oldal címe **Általános beállítások**. Itt kapcsolod a tűzfalat, és itt állítod a kéréskorlátot.

| Beállítás | Alapérték | Mit csinál | Mikor állítsd |
|---|---|---|---|
| **Firewall engedélyezése** | Be | Főkapcsoló. Kikapcsolva a worker semmit nem ellenőriz: kéréskorlát, bot-, IP- és országtiltás, kitiltások mind kimaradnak. A belépés-, regisztráció-, jelszó-visszaállítás- és hozzászólás-védelem és a biztonsági fejlécek sem futnak. Az admin-riasztás és a kétlépcsős belépés ettől független. | Csak hibakereséskor, ideiglenesen. |
| **Tároló backend** | Automatikus felismerés | Hová kerülnek a számlálók és a kitiltások: **Automatikus felismerés**, **APCu**, **Redis** vagy **Fájl**. Az automatikus előbb az APCu-t, aztán a Redist, végül a fájlt próbálja. A nem elérhető lehetőség mellett „(ezen a szerveren nem elérhető)” áll. A Redis-kapcsolat címe fix: `127.0.0.1:6379`. A fájltároló helye `wp-content/cache/lw-firewall/`. | Több PHP-folyamatnál vagy szervernél a Redis a közös tároló. Ha nincs más, a Fájl is működik. |
| **Rate limit** | 30 | Ennyi kérést engedélyez egy IP-nek az időablakon belül (1–100 000). A WooCommerce-szűrőkre, a bejelentkezésre, a REST-re, az XML-RPC-re és minden más védett végpontra vonatkozik. A bejelentkezett felhasználók a REST-, szűrő- és kosárkéréseknél tízszeres keretet kapnak. | Nagy forgalmú boltnál emeld. |
| **Időablak** | 60 másodperc | Az időablak hossza (1–86 400 másodperc). | Ritkán kell. |
| **Rate limit művelet** | 302 átirányítás (filterek eltávolítása) | Mit kap, aki túllépi a korlátot: **302 átirányítás** a paraméterek nélküli címre, vagy **429 Túl sok kérés**. **Csak a WooCommerce-szűrő- és kosárlink-kérésekre vonatkozik**; minden más végpont mindig 429-et ad. | Ha a túllépő szűrőkérést inkább hibával utasítanád el. |
| **WooCommerce-szűrők** | Be | A termékszűrő-URL-eket csak olyan látogató kapja meg, akinél megvan az oldal által JavaScripttel beállított süti. Ha hiányzik, egy apró oldal beállítja, és újratölti ugyanazt a címet. A valódi látogató ebből szinte semmit nem vesz észre. A bejelentkezett felhasználók és az engedélyezett IP-k ellenőrzés nélkül mennek át. Csak aktív WooCommerce mellett hat. | Botáradattól szenvedő boltnál maradjon bekapcsolva. |
| **Googlebot engedélyezése** | Ki | Az ellenőrzött Googlebot süti nélkül is lekérheti a szűrő-URL-eket. Az ellenőrzés DNS-lekérdezéssel megy, egy napig gyorsítótárazva. | Csak ha a szűrt oldalakat indexeltetni akarod. Kikapcsolva jobb: a szűrőkombinációk indexelése feleslegesen fogyasztja a feltérképezési keretet. |
| **Kosárba tevő linkek** | Be (új telepítés) | Ugyanez a sütiellenőrzés a `?add-to-cart=` paraméteres linkekre. A kosárba tevő űrlapokat és az AJAX-kéréseket nem érinti. | Régi oldalon, frissítés után kikapcsolva marad: kapcsold be kézzel. |

## Amit a látogató lát

Ha a böngészőben ki van kapcsolva a süti vagy a JavaScript, a látogató egy rövid oldalt kap, az oldal nyelvén:

- szűrésnél: „A szűréshez engedélyezni kell a sütiket.” vagy „A szűréshez JavaScript szükséges.”, és egy **Tovább szűrők nélkül** link;
- kosárlinknél: „A kosárba tételhez engedélyezni kell a sütiket.” vagy „A kosárba tételhez JavaScript szükséges.”, és egy **Tovább kosárba tétel nélkül** link.

## Régi oldal frissítése

Ha egy beállítást sosem mentettél, frissítés után ezek kikapcsolva maradnak: az `xmlrpc.php` kéréskorlát, a hozzászólás-védelem és a **Kosárba tevő linkek**. Új telepítésen bekapcsolva indulnak. Nézd át őket a frissítés után.