*** Settings *** Resource ${CURDIR}/../resources/common.resource Resource ${CURDIR}/../resources/auth.resource # Test IP — stable across runs so teardown can reliably unban it. # Chosen from a non-routable test subnet (RFC 3927). # Must NOT overlap with any ignoreip rule in the fail2ban jail config. Suite Setup Login As Admin *** Test Cases *** Simulated Failed Logins Appear As Ban Records [Documentation] Verifies the full ban pipeline: ... fail2ban log parsing → fail2ban ban → backend socket poll → UI rendering. ... ... Key timing facts: ... - simulate_failed_logins.sh writes 5 lines (COUNT=5). ... - manual-Jail maxretry=3 → ban triggers after 3rd matching line. ... - fail2ban backend=polling → fail2ban re-reads auth.log on its own schedule. ... - Backend has no push mechanism; /api/bans/active queries fail2ban on demand. ... - history_sync runs every 300 s; history page reads from the archive DB. ... - A direct API assertion (Step 3) isolates backend from UI rendering issues. [Teardown] Run Process ... bash ... ${CURDIR}/../../Docker/check_ban_status.sh ... --unban ... 192.168.100.99 ... timeout=30s shell truncate -s 0 ${CURDIR}/../../Docker/logs/auth.log # Step 1 — write authentication-failure lines ${result}= Run Process ... bash ... ${CURDIR}/../../Docker/simulate_failed_logins.sh ... 5 ... 192.168.100.99 ... timeout=15s Should Be Equal As Integers ${result.rc} 0 # Step 2 — wait for fail2ban to process the ban # polling backend; no fixed interval but the ban is near-instant once detected. Sleep 15s # Step 3 — backend API: confirm ban is visible via fail2ban socket query ${resp}= GET ${BACKEND_URL}/api/bans/active expected_status=200 Should Contain ${resp.text} 192.168.100.99 # Step 4 — History page: confirm UI surfaces the ban record Go To ${FRONTEND_URL}/history?page_size=500 Wait For Elements State css=table,tbody visible timeout=20s Get Text body contains 192.168.100.99 # Step 5 — confirm jail name is shown alongside the IP Get Text body contains manual-Jail