Forum Discussion
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
- iaineNacreous
Hi
You need to set your cookie in your response so that the browser will present it when it next requests an object. Have a look at the first example in HTTP::respond for an example on how to do this
- Per_HagstromNimbostratus
And for anyone who might be interested in the iRule I created, here it is:
when HTTP_REQUEST { if {[string tolower [HTTP::path]] equals "/secretpage"} { set ckname "SecretCookie" set ckvalue "1" set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue ".domain.org"] HTTP::respond 302 Location "https://[HTTP::host]/wp-login.php" "Set-Cookie" $cookie } if {[string tolower [HTTP::path]] contains "/wp-login.php" and (![HTTP::cookie exists "SecretCookie"])} { HTTP::redirect "https://[HTTP::host]/restricted-access-page" } }
Tested it out, and it seems to work perfectly! And since the "/secretpage" doesn't exist on the web server, good luck to the pesky hackers trying to brute force the login page now! 🙂
/ Per
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com