Building on the foundations of page proups and visitor groups, policies allow you to express what should happen when a visitor visits a certain page. Here are some examples of policies that you can craft within the context of Gatekeeper:
- Require suspicous IP addresses, as identified by FireHOL or belonging to a popular cloud platform, to successfully complete a CAPTCHA challenge when registering an account, but do not impose the same requirement on non-suspicious IP addresses
- Require IP addresses that submit ten incorrect login attempts in ten minutes to successfully complete a CAPTCHA challenge, and ban the IP addresses that ignore successive CAPTCHA challenges (tutorial)
- Slow down forum spammers by allowing no more than fifteen comments per fifteen minutes
- Direct anonymous visitors who have read more than five pieces of content over the last thirty days to register for an account (tutorial)
- Enforce robots.txt conventions for robots that declare themselves (e.g. if a self-declared robot visits restricted pages, transmit empty content)
- Ask suspected bots to answer a CAPTCHA challenge and ban IP addresses that ignore CAPTCHA challenges
At first, the number of options for policies can seem overwhelming. Taking a look at the pieces, though, policies involve four components: who, what action, how often, what response.
Which visitor groups should the policy apply to? A policy can target multiple visitor groups. Alternatively, you can invert the selection and have the policy apply to any visitor not in the list of visitor groups.
You can also modify the targeting by customizing the policy depending on the user-agent. For example, if the visitor self-identifies as a bot and is visiting a page that is prohibited by robots.txt, then maybe you want to put that IP address on a bad bot list. Alternatively, if a self-identified bot is making its way through the allowed content, maybe you never want to show it a CAPTCHA challenge, even though you might want to occasionally challenge humans that are visiting many of your URLs.
We use the term "self-identified" since bots can easily masquerade as human run browsers, and simply saying "bots" might imply that we actually know whether the software is a bot or not.
What is the visitor doing? The visitor could be visiting a page (or page group), and you might want to customize the response based on the URL that is being visited. For example, maybe you want to craft a policy that any visitor can always visit the website's About page, but you might be pickier about access to the website's product pages. Alternatively, you can decide what should happen when a visitor encounters a CAPTCHA and fails it, ignores it, or successfully completes the challenge.
Maybe any visitor can visit a page, but a visitor who visits twenty URLs in five minutes should go to the time-out corner for a little while. Likewise, a visitor who ignores ten CAPTCHAs in one minute might not actually be a human despite not identifying itself as a robot.
How do you want your website to respond? Allow the visitor? Deny the visit? Show a CAPTCHA challenge? Gatekeeper communicates the result of your policies by sending a visit authorization. If you want a custom authorization, you can create your own.
You can also automatically ban the visitor by adding the visitor to a blacklist (i.e. if a visitor is egregiously misbehaving, you can not only deny this particular visit, but you can add it to a ban list so that future visits are also denied, even if those visits don't trigger this particular policy). Membership in lists can be set for a period of time; for instance, you can ban an IP address for 30 days, after which it will be removed from the list.
Reason: this field is provided as a convenience so that Gatekeeper clients can specify messages through the web interface instead of including the message text in the website code. This field is provided as a part of the response to the client's call, so it can choose to present the message to the user (e.g. "Your IP address has been temporarily banned. If you think this ban is in error, please call 800-XXX-XXXX and sing "Happy Birthday" to have your access restored).
Description: a purely internal field where Gatekeeper users can keep notes.
Priority: Each policy has a priority. When deciding what response to return to the client, Gatekeeper will go through the list of policies (starting with the highest priority ones; the larger the number, the higher the priority) and will stop at the first applicable policy.
Status (enabled/disabled): Allows you to temporarily disable a policy rather than deleting it.
To learn more about how Gatekeeper applies its rules engine to come to a decision, check out our page on computing visit authorizations.