qr-reader: register all server-language extensions (reader posts .jsp)

Hardware capture: the GEE/Fondvision reader (serial H05M2AFA) scans + sends +
beeps fine — the earlier 'no beep' was just nothing answering :3000. Real
request: GET /qa/mcardsea.jsp?cardid=...&cjihao=H05M2AFA&... — the 'server
language' setting (JSP here) selects the URL EXTENSION, so it posts .jsp, not
.php. Our route was .php-only and would have 404'd it.

Register the endpoint at php/jsp/asp/aspx/cgi so it works whatever the device is
configured to. cjihao (serial) is the lane key: assign the reader as
lane_devices.id = its serial.
This commit is contained in:
2026-06-16 12:30:00 +02:00
parent 392d44d842
commit 04135b27cf
3 changed files with 46 additions and 11 deletions
+25 -6
View File
@@ -71,10 +71,29 @@ barrier. ([[device-input-flow]] is the analogous push pattern; this one also ret
- Verified via inject: valid permit QR → `status:1` + open; re-scan → permit exit (still valid);
unknown QR → `status:0`; reader on a barrier-less lane → `status:0`.
## Open / to confirm on hardware
## Verified on hardware (2026-06-16)
- A **live scan** still hadn't reached the server during bring-up (no beep). With the real endpoint
now replying the verdict, re-test: scan → expect a beep + a GET in the server log. If still
nothing, it's the reader's scan/trigger/mode (not the server).
- **Reader→lane identity:** confirm what the device actually sends as `cjihao`/`mjihao` and align the
`lane_devices` assignment (the wizard doesn't yet capture the reader's serial as its id).
Captured a real scan (vendor-emulator logger on :3000). The reader **does scan, send, and beep** —
the earlier "no beep" was simply that no server was answering on :3000 with valid JSON. Real GET:
```
GET /qa/mcardsea.jsp?cardid=52020056&mjihao=1&cjihao=H05M2AFA&status=11&time=1781634494
from 10.0.10.7 (referer: http://www.fondvision.com — the OEM is Fondvision)
```
- **PATH carries the configured "server language" EXTENSION:** this unit is set to **JSP**, so it
GETs **`/qa/mcardsea.jsp`** — NOT `.php`. Our endpoint was registered at `.php` only → it would
have 404'd the real reader. **Fixed:** the route now registers `php/jsp/asp/aspx/cgi`.
- **`cjihao` = `H05M2AFA`** is the device **serial** — the value our endpoint keys the lane on. So
assign the reader with **`lane_devices.id = "H05M2AFA"`** (+ an access device on the same lane).
- **`mjihao` = 1** (device id). `cardid` = the scanned barcode (`52020056`). `status=11`.
- The reader **beeped on the vendor reply with `status:0`** — so it acts on the reply; `0` =
invalid/1-beep as documented. A matching permit/session will return `status:1` → 2-beep accept.
## Open / next
- **Assign the reader** as `lane_devices.id = "H05M2AFA"`, category `reader`, on the same lane as an
access device, so the endpoint resolves the lane. (The setup wizard doesn't yet capture a reader's
serial as its id — manual row or a wizard tweak; see [[first-run-setup]].)
- Re-test against the real app endpoint (now `.jsp`-aware): scan → expect the GET to hit
`/qa/mcardsea.jsp` and a `status:1` 2-beep when the credential matches a permit/open session.