Forum Discussion
Per_Hagstrom
Nimbostratus
NimbostratusSimple WordPress login protection using referral
I'm trying to protect the default login page (/wp-login.php) on our WordPress site, using a "secret" (/secretlogin) page as a referral, and only then should you be able to login: (otherwise you get redirected to a restricted access page)
when CLIENT_ACCEPTED {
set static::triggerWP 0
}
when HTTP_REQUEST {
if {[string tolower [HTTP::path]] contains "/wp-login.php" and $static::triggerWP == 0 } {
HTTP::redirect "https://[HTTP::host]/restricted-access"
}
if {[string tolower [HTTP::path]] equals "/secretlogin"} {
set static::triggerWP 1
HTTP::redirect https://[HTTP::host]/wp-login.php
}
}
And this seems to work pretty well in our test environment, but when I added this to our Prod environment, which has lots of traffic, it is very rare for this to work. I'm guessing the heavy traffic resets the triggerWP variable to 0, and that this variable isn't unique to each person who connects? Any idea how I could handle this better? Thanks!
Dave_McCauley_3Cirrostratus
Drop the static variable and see if that helps. Static variables are put into the tmm's global namespace, i.e. even other iRules would see this variable and generally shouldn't be used. If you use a standard variable, you'll have it be distinct for each new connection, which is what I think you want here.
https://devcentral.f5.com/wiki/iRules.static.ashx
-Dave
Per_HagstromDave,
Great! Yes, that seems to have fixed the problem! Thank you very much! 🙂
/ Per
ps. in case someone else would like to use this iRule, here is the corrected code:
when CLIENT_ACCEPTED { set triggerWP 0 } when HTTP_REQUEST { if {[string tolower [HTTP::path]] contains "/wp-login.php" and $triggerWP == 0 } { HTTP::redirect "https://[HTTP::host]/restricted-access" } if {[string tolower [HTTP::path]] equals "/secretlogin"} { set triggerWP 1 HTTP::redirect https://[HTTP::host]/wp-login.php } }
- Per_Hagstrom
Well, at first that seemed to have fixed it, but we are still getting "random" problems, and sometimes really bad, where you can try over and over, and we just get redirected to /restricted-access. Very inconsistent. Which means triggerWP gets set back to 0...! How can that be, when that's only supposed to happen when 'CLIENT_ACCEPTED'??
Is there a better way to handle this?
- Per_Hagstrom
Opened a ticket about it, and support says the problem might be because a browser may make multiple connections... causing the triggerWP to get reset to 0 again, which then causes the redirect to the restricted page. They suggested to do a cookie insert to the client browser instead. So I will start a new thread about it instead.