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 as identified as 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 "self-identified" since bots can easily masquerade as normal 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 maybe a visitor who visits twenty URLs in five minutes should go to the time-out corner for a little while. Likewise, a visitor that 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, so if you only want to ban an IP address for 30 days, you can set that.
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 removed).
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 (staring with the highest priority ones; a larger priority number is higher priority over a smaller priority number) and will stop at the first applicable policy.
Enabled: Sometimes, users might want to temporarily disable a policy and not delete it.
To learn more about how Gatekeeper applies its rules engine to come to a decision, check out our page on computing visit authorizations.