| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 3635 |
| Technical Name |
eh_hr_face_liveness |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 3635 |
| Technical Name |
eh_hr_face_liveness |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Face Liveness
An active liveness check sat in front of the face match. The kiosk shows a blink prompt; the browser tracks the eye landmarks face-api.js already loaded; the embedding capture only runs once enough blinks are detected. Stops a printed photo or a phone screen held at the camera, with every attempt audited.
Day in the life
"Please blink slowly twice." Two real blinks later, the day starts.
A worker steps up to the kiosk. The face kiosk would normally start the embedding loop straight away. With liveness installed, the welcome screen hands off to a prompt: blink slowly twice. The browser watches the eye aspect ratio over a configurable window, counts blinks, and only signals pass once the threshold is met. On pass, the kiosk continues into face match. On fail or timeout, the kiosk shows a polite retry screen. Every attempt, pass, fail, or aborted, lands in eh.hr.liveness.check, so a fortnightly review can spot the depot where the spoof attempts cluster.
Overview
What this module does, in one read.
eh_hr_face_liveness slots an active blink check into the kiosk welcome to capture transition.
The kiosk shows a prompt, the browser tracks the eye landmarks face-api.js already loaded for the match step, and the embedding capture only proceeds on a passing detection. Every attempt is logged so a manager can see fail patterns over time. A daily retention cron deletes rows older than the configured horizon (default 180 days).
Capabilities
Eight things this module gives you, with no padding.
Active blink prompt
The kiosk asks the user to blink, watches the eye aspect ratio between the face-api.js landmarks already loaded for the match step, and only proceeds on a passing detection.
Photo attack defence
Blocks the simplest spoof: a printed photo or a phone screen held at the kiosk camera. The match cannot run until the prompt passes, so a static image cannot trigger an attendance row.
Per company configuration
Toggle the gate on or off per company, set the required blink count (default 2), and set the maximum wait in milliseconds (default 8000) before the attempt is declared failed.
Every attempt logged
eh.hr.liveness.check stores one row per attempt with outcome, prompt shown, duration, blinks detected, fail reason, device, site, and (after match) the employee. Read only for managers, queryable.
Three outcomes, no ambiguity
Passed, failed, or aborted. Aborted means the user walked away mid prompt; failed means the timeout elapsed without enough blinks; passed means the threshold met. Filters and dashboards know which is which.
Daily retention sweep
A daily cron deletes attempt rows older than the configured horizon (default 180 days), batched so a database with months of stale rows does not freeze a worker.
Wired into the kiosk shell
The kiosk JS hook intercepts the welcome to capture transition; no template work in the consuming module. Install, configure, and the gate slots in.
Honest about the limits
Detection runs in the browser; the server only audits what the browser claimed. A determined attacker who controls the device can fake the outcome. For high security exposure, layer this on top of a paid passive liveness model.
Compared
How this module stacks up.
Workflow
Install. Toggle on. Tune. Watch.
Install
Pick eh_hr_face_liveness. Depends on the suite base and the face kiosk.
Toggle on
Open Settings under People Operations. Enable the liveness check on the company. The kiosk picks it up on the next page reload.
Tune
Set blinks required and the timeout. Defaults of two blinks within eight seconds work for most sites; raise either if false positives bother you.
Watch
Open the Liveness Checks list. Filter by failed or aborted to find sites with a sudden spike of suspicious attempts.
Frequently asked questions
Honest answers to the questions a buyer asks.
Will this stop a printed photo of an employee?
Yes for a static print. The blink prompt requires real eye motion the printed image cannot produce. A video on a phone screen is harder; a determined attacker with a high refresh rate display and a video clip of the target may still pass.
How long does the gate add to a clock in?
In testing, a cooperative user passes within one to two seconds. The default eight second timeout sets the upper bound on a failed attempt.
Is detection done on the server?
No. The browser uses the face-api.js landmarks already loaded for the match step. The server only audits what the browser claims, so a determined attacker controlling the device can fake the outcome. For high security paths, layer this on top of a paid passive liveness vendor.
Can I keep the gate off but still log attempts?
No. The toggle controls both the prompt and the row write. With the gate off, no liveness rows are produced. Switch the gate on for the audit trail.
How long is data retained?
Each attempt row is kept for the configured horizon (default 180 days), then deleted by a daily retention cron.
Please log in to comment on this module