Forum Discussion

Per_Hagstrom's avatar
Per_Hagstrom
Icon for Nimbostratus rankNimbostratus
Feb 25, 2019

Simple 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!

BIG-IP
devops
irule
iRules
protect login
referer
  • Dave_McCauley_3's avatar
    Dave_McCauley_3
    Icon for Cirrostratus rankCirrostratus
    Feb 25, 2019

    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_Hagstrom's avatar
      Per_Hagstrom
      Icon for Nimbostratus rankNimbostratus
      Feb 26, 2019

      Dave,

       

      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's avatar
    Per_Hagstrom
    Icon for Nimbostratus rankNimbostratus
    Feb 27, 2019

    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's avatar
    Per_Hagstrom
    Icon for Nimbostratus rankNimbostratus
    Feb 27, 2019

    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.