Skip to main content
FomiVIP
Tech Sharing

QR-Code Asset Audits: Pitfalls in the Scan API

Phase two of a lab asset ledger: 43 devices, each with a QR code for scan-based audits. Guessable auto-increment ids in the QR URLs pushed us to random tokens. More pitfalls: WeChat's scanner truncating parameters, unrevoked reprinted labels, and a signal-less basement needing offline catch-up.

October 15, 2020QR CodesAsset LedgerLessons Learned

Phase two of the lab asset ledger: 43 devices, one QR code each; admins scan with their phones to open the detail page and record an audit. It sounds like half a day's work. It took a week. Here is what bit us.

1. The QR Code Encoded the Auto-Increment id

The first script embedded the device's auto-increment id straight into the URL, like /asset/17. The labels were printed and stuck on; someone on the client's side scanned one, casually changed 17 to 18, and up came another device's information. Device info isn't sensitive, but 'guessable' is unacceptable in itself.

We switched to random tokens, 16 characters, with a separate asset_token mapping table; the QR code contains only the token. The generator also became a one-shot batch: 43 labels, filenames carrying the device name, sequence numbers never exposed.

2. WeChat's Scanner Ate a Parameter

The QR URL carried two parameters: token and source. Scanning with the system camera worked fine; opening via WeChat's 'Scan,' the second parameter occasionally vanished. After much digging: the & in the URL was being treated as a terminator in some contexts. We reduced it to a single token parameter and resolved the source server-side by token. Two parameters became one.

3. Old Labels Weren't Revoked, So We Double-Printed

Halfway through sticking the first batch we found one device mislabeled, printed a replacement, and didn't fully peel off the old one. Result: the same device appeared twice in the audit sheet. We added a status field to the tokens — revoked labels now respond 'label invalidated' when scanned — and put a unique index on asset_id per audit day, one record per day.

4. The Basement Has No Signal

One lab is downstairs where phones get essentially nothing. Admins scanned, the page wouldn't open, and back upstairs they forgot about it. The fix: after scanning, the record is first stored in the browser's localStorage; when the page detects connectivity it auto-uploads with a client-generated uuid, and the server deduplicates on the uuid. That round recovered seven records, all from the same day.

5. The Export Still Needs to Be Printable

After the audit the client wanted a paper sheet to sign and file. We built an export: A4 portrait, one column each for device name, code, audit status, and remarks — 43 rows, exactly two pages. The font size was deliberately set to 10; any smaller and the signatures can't be read back.

Wrap-Up

All 43 devices were scanned in the end. The system showed one more than the ledger — a centrifuge written off long ago but never removed from the books. The equipment manager took the paper sheet to process the write-off. That part had nothing to do with the system.

We kept a stack of the revoked labels. They're still sitting in a drawer at our Optics Valley office.

Consulting · Free initial chat

Need advice for your scenario?

Tell us your business context and current systems, and we'll give an actionable approach.

Contact us

Mon–Fri 9:00–18:00 · We respond on business days within one business day.

WeChat (Business Only)
WeChat (Business Only)二维码

Scan and add our WeChat for consulting

Or fill out the requirements form