Skip to main content
FomiVIP
Service Cases

SSO Plus DingTalk QR Sign-In for a Microsoft China Event Site

Another event site for Microsoft China: passwordless entry for internal staff via SSO, QR check-in for guests via DingTalk, both landing in one check-in sheet. One pitfall: DingTalk's callback timestamp is in milliseconds, and verifying signatures in seconds kept failing until we spotted it.

May 16, 2025Single Sign-OnQR Sign-InEvent Sites

Our second event site for Microsoft China. The pages were even simpler than the 2020 one, but identity got more complex: internal staff click a link and walk straight in; external guests scan a QR code on-site; everything lands in the same check-in sheet.

Two Paths

Staff go through SSO. The link embedded in the OA carries an encrypted ticket; the backend decrypts the mail_prefix, looks up roles in the identity table — the same approach as our 2019 internal forms, with tickets valid 5 minutes and single-use.

Guests scan via DingTalk. A QR code on a floor stand redirects with a temporary code; the backend exchanges it for user info, writes a guest record, and issues a temporary credential valid 2 hours. No registration required, no phone number collected.

Both paths converge into one check-in table structure: person_type, person_id, name, source, check-in time, and session — six fields. When reports split into sheets by session, staff and guests stay mixed, sorted by check-in time, never separated.

The Signature Verification Pitfall

DingTalk's callback carries a timestamp and signature. We computed the signature the standard way with the timestamp and secret, and verification kept failing with 401s. After much digging: the timestamp was 13-digit milliseconds, and we had copied the seconds-based example from the docs verbatim. Dividing by 1000 before signing fixed it.

While at it, we set a 5-minute time tolerance to absorb clock drift between phones and server. Replays are blocked by a nonce set held in Redis for 10 minutes.

On-Site

May 16, doors at 9 a.m. Over 400 check-ins in the first hour — 100+ staff and just over 300 guests. The two entry paths ran independently, and the check-in desk watched one sheet on one computer with no system switching.

One hiccup: a guest scanned, closed the page, returned, and rescanned — creating a second guest record. We later merged duplicates by the unique userid DingTalk returns, pointing repeats at the same record. Statistics were unaffected.

How the Two Identities Line Up

Staff and guests land in the same check-in sheet, but their person_ids come from different worlds: mail_prefix for staff, DingTalk's userid for guests. The report can mix them because we never compare those two columns directly — a separate person_type column distinguishes them. The first version tried to unify everything into one id; halfway through we realized it was unnecessary and risked misclassifying external guests as internal staff.

One detail: some staff brought family members, entering through the staff path but supplying guest information. These are marked "staff + guest" in the sheet — counted as 2 for attendance, 1 for staff presence. The client set that rule themselves; our job was simply to keep both columns intact and not decide the count for them at export time.

Those 2 Hours of Temporary Credentials

The 2-hour validity was set from the event's duration, with a little margin. Anyone who truly returned after leaving found their credential expired; rescanning shows "This session has ended, please see the check-in desk" and no new record is created. Three people came back that day; the desk admitted them manually, one note each in the remarks.

The userid-based merge went live at noon on event day. That morning a guest's rescan had produced two records; once support spotted it, we changed the logic: one record per userid per session, later scans pointing to the first. A small change, deployed before the afternoon rush — no duplicates after.

Floor Stands and Tape

It was windy that day; the stand at the door tipped over once and admin taped it back. Nothing else went wrong technically. Afterward someone asked whether next time the QR code could be printed directly on the check-in desk surface — one less thing to prop up. That note went into the event retrospective, not the requirements doc.

The client later turned the 7-column CSV into a simple bar chart, two groups by source — they built it themselves, without asking us. Nicely done. During the retrospective they also reviewed the three manual-admission remarks and said "clear writing is all we need." The tape came off eventually; the stand went into storage.

The Export

After the event we exported a 7-column CSV, color-coded by source, for the client to reconcile against the invitation list. The staff portion needed no reconciliation — they were already on the roster.

The wind in Beijing that day was strong; the door stand tipped once and admin taped it back. Technically, nothing else went wrong.

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