Simple WordPress login protection, using cookie insert
I'm trying to deny access to the default login page on our WordPress site, when going straight to the login page (/wp-login.php), by redirecting you to /access-denied. But if you know the "secret" page, https://[HTTP::host]/secretpage , then the iRule should put a cookie in your browser, then redirect you to the actual login page, and now allow you to login. Any suggestions on how this could be done? Tried something like this, but not getting the expected result: when HTTP_REQUEST { if {[string tolower [HTTP::path]] equals "/secretpage"} { HTTP::cookie insert name "SecretWP" value "1" HTTP::redirect https://[HTTP::host]/wp-login.php } if {[string tolower [HTTP::path]] contains "/wp-login.php" and (![HTTP::cookie exists "SecretWP"])} { HTTP::respond 200 content "Rejected! Cookie names: [HTTP::cookie names]" } } In the end I added a HTTP::respond 200 content, for HTTP::cookie names, for troubleshooting, but the cookie I tried to insert was not in the list. Made this iRule sort of based on an example I found on the F5 site, but most other example seems to always add the cookie insert when HTTP_RESPONSE, so I'm wondering if that's the problem? Can't do an insert when HTTP_REQUEST? / Per
Fallback Persistence Profile - how it works
Hi, I don't know if this is bug or correct behavior - tested on 11.2.0 Setup: VS with Default Persistence Profile: cookie insert Fallback Persistence Profile: source address Result: First request from client (without cookie): Set-Cookie header in response setting BIGipServer... cookie Persistence Record (PR) created - makes sense because there was no cookie in client request Second request from client Cookie send in request PR timeout refreshed - could be OK as PR exists matching client IP but because Cookie is provided why it's used? Third request - after PR was manually deleted Cookie send in request PR record created Why PR is recreated when cookie exists? Which persistence is in fact used - cookie or source address? Piotr
Fallback Persistence Profile - how it works
Hi, I don't know if this is bug or correct behavior - tested on 11.2.0 Setup: VS with Default Persistence Profile: cookie insert Fallback Persistence Profile: source address Result: First request from client (without cookie): Set-Cookie header in response setting BIGipServer... cookie Persistence Record (PR) created - makes sense because there was no cookie in client request Second request from client Cookie send in request PR timeout refreshed - could be OK as PR exists matching client IP but because Cookie is provided why it's used? Third request - after PR was manually deleted Cookie send in request PR record created Why PR is recreated when cookie exists? Which persistence is in fact used - cookie or source address? Piotr