How do I see how many times a client has failed Advanced CAPTCHA and how close it is to quarantine?
Short answer
If Captcha Quarantine is on in the Advanced CAPTCHA action, the action name (TRACKING, duration) source is selected in the Logs & Tracking tab of the vService. The table lists the clients that failed CAPTCHA verification by the Tracking Type key (default IP); the Incorrect Answers column shows the number of failed attempts within the Quarantine Tracking Window together with the threshold in the attempts/threshold format (e.g. 2/3). The counter increases only on a failed verification, and a correctly solved CAPTCHA does not reset it; a client that reaches the threshold moves to the (QUARANTINE, duration) source. The table does not record why a CAPTCHA was shown to the client: the CAPTCHA is shown when the Conditions field of the action is met and the client does not have a valid verification cookie. If Captcha Quarantine is off, no tracking table is created.
Problem: It Is Not Visible Which Client Is Stuck at the CAPTCHA
When a user reports that they cannot pass the CAPTCHA or cannot access the site, two things are wanted to be known: how many times the client gave a wrong answer and how much is left before it is quarantined. Since the Advanced CAPTCHA action has no Hit Counter, the number of times the action ran is not counted; failed attempts are tracked only in the tracking table of Captcha Quarantine.
The reason a CAPTCHA is shown to the client is the same on every request: the request matches the conditions in the Conditions field of the action and the client does not have a valid verification cookie. The cookie is bound to the IP address and the browser of the client and becomes invalid when the Captcha Valid for period (default 24 hours) expires; therefore, a CAPTCHA is shown again to a user whose IP address changes or who changes browsers (How Does Advanced Captcha Work?).
Solution: Two Methods
The two tables are two stages of the same action: the client is first counted in the tracking table and moves to the quarantine table when it reaches the threshold.
| Your situation | Suitable method |
|---|---|
| I want to see the number of failed attempts of the client and its distance to the threshold | Method 1: Logs & Tracking → (TRACKING, …) source |
| The client has been quarantined; I want to see when it will be released or to release it | Method 2: Logs & Tracking → (QUARANTINE, …) source |
Method 1: Logs & Tracking → (TRACKING, …) Source Recommended
- How it worksAdvanced Captcha (Tracking) Logs is not a recorded history but the current content of the tracking table. Each row is a client; the Incorrect Answers column shows the number of failed verifications within the window as
attempts/threshold. The value decreases as the window slides; the row is removed from the table at the Expiry Date time. - Where it is opened Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking
- Requirement An Advanced CAPTCHA action with Captcha Quarantine on, added to the vService (Captcha Quarantine is off by default)
- vService type HTTP
Step-by-Step Configuration
If Captcha Quarantine is off, there is no tracking table. On the Load Balancer → Actions screen, the Advanced CAPTCHA action is selected and the Edit button is clicked; the form opens on the Edit Action tab (Edit). If Captcha Quarantine is already on, this step and the next two steps are skipped.
Captcha Quarantine is enabled. Tracking Type (default IP), Quarantine Failure Threshold (default 3; 1–100), Quarantine Tracking Window (default 5 minutes; 10 seconds–24 hours) and Quarantine Duration (default 30 minutes; 1 minute–30 days) are set.
The Edit button at the bottom of the form is clicked.
In the Left Monitor Panel, Load Balancer vServices is selected, the vService is clicked and the Logs & Tracking tab is opened.
The (TRACKING, …) entry of the Advanced CAPTCHA action is selected from the Logs Type list (e.g. login-captcha (TRACKING, 5m)).
Refresh is clicked; the list does not refresh on its own.
The address of the user is written in the Search box, or the list is filtered by the ↓IP value with Filter. When the row is clicked, the Incorrect Answers value appears in the preview together with the tracking window (e.g. 2/3 / 5 minute(s)); Last Event shows the time of the last failed attempt, and Expiry Date shows the time the row will be removed from the table.
The counter of a user who was counted by mistake is reset by selecting the row and using Remove from Table; the toolbar and the right-click menu ask for confirmation, while the trash can in the preview does not ask for confirmation. This operation does not release a quarantined client.
Verification
From the test client, the CAPTCHA is deliberately answered wrong once, and then Refresh is clicked.
Incorrect Answers = 1/3 in the client's row (at the default threshold)Method 2: Logs & Tracking → (QUARANTINE, …) Source
- How it works A client that fails as many times as the threshold within the tracking window moves to the Advanced Captcha (Quarantine) Logs table and is met with the Quarantine Action throughout the Quarantine Duration. The quarantine is applied across the whole vService, independently of the condition of the action.
- Where it is opened Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking
- Requirement Same as Method 1
- vService type HTTP
Step-by-Step Configuration
Step 4 of Method 1 is applied, and the (QUARANTINE, …) entry of the same action is selected from the Logs Type list; then Refresh is clicked.
The Quarantine Start and Quarantine Expiry values are read in the row of the client. If access needs to be opened before the period expires, the row is selected and removed from quarantine with Remove from Table (How do I see the clients in quarantine?).
Verification
The client that reached the threshold in the tracking table is searched for in the quarantine source.
The client is listed with the Quarantine Start and Quarantine Expiry valuesCommon Mistakes
- Looking for the reason the CAPTCHA was shown in the tracking table. The table counts only failed verifications; it is not kept on which request and why the CAPTCHA was shown. The reason is the Conditions field of the action; an action saved without a condition shows a CAPTCHA to all the requests that come to the vService.
- Thinking a correct solution resets the counter. A correctly solved CAPTCHA does not reset the counter; the value decreases only as the window slides. To reset the counter immediately, Remove from Table is used.
- Looking for a table while Captcha Quarantine is off. The tracking and quarantine sources are created only while Captcha Quarantine is on; if they do not appear in the Logs Type list, the feature is off.
- Thinking deleting the tracking row removes the quarantine. Deleting from the tracking table only resets the counter; a quarantined client is removed from the (QUARANTINE, …) source.
- Not taking the Tracking Type into account. If the tracking key is a combination such as IP + User-agent or V-Host + IP, different browsers or domain names coming from the same address are counted in separate rows; if the client is searched for only by IP, one of the rows can be missed.
How it is done in the documentation
