# How Wicket works

> Follow one Wicket check from your page to your server, through the script, the frame and the token, and see when a visitor ticks a box or is refused.

Source: https://www.coritan.com/docs/wicket/how-wicket-works/

Wicket answers one question for your server: is a person, in a browser, sending this form from one of your pages? It answers in two places. A widget on your page checks the visitor's browser and hands the form a token. Your server then asks Wicket whether that token is real before it accepts the form.

Each time a visitor's browser runs the check, that is one *challenge*. The **Analytics** tab of the widget counts challenges, and the *solve rate* is the share that passed ([Read a widget's analytics](/docs/wicket/widget-analytics/)).

## A check from start to end

### The page loads the script

Your page includes one script from Wicket and one container with the class `wicket-widget` and your *site key*. The script draws a small frame in the container. The frame comes from Wicket's own host, so your page cannot read what happens inside it, and Wicket learns your page's hostname and the `action` and `cdata` you set, and nothing else about the page.

Before the frame does anything, Wicket checks that the widget exists, that our team has not turned it off, and that the page's hostname is one of the widget's hostnames. A page on any other hostname gets no challenge.

### The frame checks the browser and does a little work

The frame starts a challenge, then does two things at once. It answers a few questions about the browser and the device, such as whether a program seems to be driving the browser. It also does a small calculation, called a *proof of work*, in the background so the page stays responsive. The calculation is small for one visitor and adds up for a script that sends thousands of requests.

The frame sends both results to Wicket. Wicket scores them, together with what it knows about the network the request came from.

### A person ticks a box only when the check is unsure

A clear pass gives the visitor a token at once. Most visitors see **Checking your browser…** and then **Success**, and do nothing.

When the score is in the middle, Wicket does not refuse the visitor. It asks for a little more. A Managed widget shows a box to tick, and the other modes ask for more work and never show a box. A person ticks the box once. It is a real checkbox, so a pointer, a finger, the keyboard and a screen reader all work.

### The form carries a token

When a check passes, the frame gives the script a *token*, and the script puts it in a hidden field named `wicket-response` inside your form. The browser sends it with the other fields. The token is tied to the widget and to your page's hostname, it works once, and it expires after 300 seconds. With the default settings, a visitor who waits longer gets a new one without doing anything.

### Your server verifies the token once

A script can send your form without loading the widget, so the token alone proves nothing. Your server posts it, with your *secret key*, to the verify address. Wicket opens the token, checks that it belongs to your widget, is not older than 300 seconds and has not been used, and answers `success`, with the hostname of the page and the `action` you set. Your server accepts the form only when the answer says `true` ([Verify a token on your server](/docs/wicket/verify-tokens/)).

## The modes

A widget's mode decides what Wicket asks of a visitor it is unsure about. Every mode runs the same check and scores it the same way ([Widget modes](/docs/wicket/widget-modes/)).

| Mode | What a visitor sees |
| --- | --- |
| Managed | Most visitors see nothing, and a few tick a box. |
| Non-interactive | No one ticks a box. A visitor Wicket is unsure about waits a moment longer. |
| Invisible | Nothing on the page. Your own code starts the check and shows any message. |

## What makes a check refuse a visitor

Wicket refuses a visitor only on near-certain evidence, such as a browser that reports that a program is controlling it. Anything less costs the visitor a click or a moment. A visitor on a VPN, in a privacy browser or on a network with a record of abuse may be asked to tick the box or to wait a little longer, and is not refused. Ticking the box with a keyboard or a screen reader never counts against a visitor.

Wicket does not publish the signals it reads or how it weighs them, because that would help a script avoid them.

## When a visitor is refused

The widget shows **We could not check this browser** with a **Try again** button, and a **Having trouble?** link in its footer. The link opens a short form with one optional field, **What were you doing?**. The note goes to Wicket with a reference to the check, and the visitor reads **Thanks. We will look at it.** The widget never says whether the visitor was taken for a bot, because that answer would help a script ([Troubleshoot Wicket](/docs/wicket/troubleshooting/#a-visitor-cannot-pass)).

Reports help us improve the check, and you can send your own from your server when you learn what a check turned out to be ([Report what a check turned out to be](/docs/wicket/verify-tokens/#report-what-a-check-turned-out-to-be)).

## No cookie and no puzzle

Wicket shows no puzzle, picture or sound, so a visitor who cannot see or hear passes the same way as anyone else. It sets no cookie and stores nothing in the visitor's browser. [Wicket and visitor privacy](/docs/wicket/privacy/) lists what the check reads and what we keep.

## Next steps

- [Add a widget](/docs/wicket/add-a-widget/) to get a site key and a secret key.
- [Add Wicket to your site](/docs/wicket/add-wicket-to-your-site/) to put the script and the container on a page.
- [Verify a token on your server](/docs/wicket/verify-tokens/) to finish the check.