Skip to content

7.3.4 · Scorecard — meeting-backoffice-new

branch: UAT

Legend:

  • 🔴 Critical = active security/data-loss/availability risk
  • 🟡 High = correctness/maintainability hazard, real impact
  • 🟢 Medium = friction/hygiene

ตารางสรุป

IDSeverityคำอธิบายหลักฐานการแก้ที่เสนอ
CORR-MTBONEW-01🔴 CriticalBundle ที่ commit ไม่มี hostname API; REACT_APP_MEETING_API / REACT_APP_2WAY_API ไม่อยู่ใน env object ที่ bake — ความเสี่ยงสูงที่ยิงไป undefined/secure/...build/static/js/main.633a23c6.js (ตรวจ inline env); ไม่มี .env* ใน repo; pages/index.tsx:19rebuild ด้วย env จริง; เพิ่ม .env.example; ตรวจ network tab บน UAT
SEC-MTBONEW-01🟡 HighHardcode Authorization: Bearer testnaja ในซอร์สและ bundlecreategroup/index.tsx:366, createapprover/index.tsx:391, bundle stringลบ; ใช้ token จริงหรือให้ backend อนุญาตแบบที่ออกแบบไว้
SEC-MTBONEW-02🟡 Highไม่มี auth flow / ไม่แนบ token บน /secure/* ส่วนใหญ่App.tsx:17-24 ไม่มี token route; fetch หน้า home ไม่มี headersdocument threat model + ปิด endpoint ฝั่ง API
QUAL-MTBONEW-01🟡 Highbuild/ commit ใน git — artifact หลุด sync กับ src/ ได้ง่ายbuild/static/js/main.633a23c6.jsCI build; .gitignore build/; หรือ mono-publish script
QUAL-MTBONEW-02🟢 Mediumต้อง copy ไป 3 โฟลเดอร์ backoffice ด้วยมือ — ไม่มี automation ใน reposha ตรงกัน 3 backoffice + repo นี้สคริปต์ sync หรือ package publish
QUAL-MTBONEW-03🟢 MediumDockerfile npm start (dev) ไม่สะท้อน static embedDockerfile:8เปลี่ยนเป็น nginx serve build/ หรือลบ Dockerfile ที่ทำให้เข้าใจผิด
QUAL-MTBONEW-04🟢 MediumBASE_PATH ใน compose ไม่มีผลต่อ CRA PUBLIC_URLdocker-compose.yml:7-8 vs package.json:5ลบ env หรือ document ว่าใช้ homepage เท่านั้น
OBS-MTBONEW-01🟢 Mediumไม่มี Sentry / error trackingpackage.json:6-27เพิ่มถ้ายังใช้ใน prod
OBS-MTBONEW-02🟢 MediumREADME เป็น CRA default — ไม่บอก embed workflowREADME.mdเขียนขั้นตอน build → copy → commit backoffice
QUAL-MTBONEW-05🟢 MediumSidebar ไม่ครบหน้า (เหมือน Next twin)Sidebar.tsx:52-68เพิ่มลิงก์หรือพึ่งปุ่มใน list ให้ชัด

สรุปภาพรวม

  1. Source of truth ของ UI ที่ฝังใน legacy backoffice = repo นี้ (build/ sha ตรง)
  2. Next meeting-backoffice = service คนละ path (/meetingbo) คนละ auth entry
  3. ความเสี่ยงใหญ่สุดตอนนี้: env ไม่ถูก bake ใน artifact ที่ commit + Bearer testnaja
  4. ไม่มี Sentry

Checklist ก่อนแก้

  1. ยืนยันว่าผู้ใช้ที่เจอบั๊กอยู่บน /meeting-backoffice (embed) หรือ /meetingbo (Next)
  2. ตั้ง REACT_APP_MEETING_API และ REACT_APP_2WAY_API ก่อน npm run build
  3. ตรวจ bundle ว่ามี hostname จริง ไม่ใช่ undefined/
  4. Sync build/vtrc-backoffice/meeting, vtrc-backoffice-new/meeting, vtrc-rc-backoffice/meeting ตามที่ทีมใช้จริง
  5. อย่าพึ่ง docker-compose.yml เป็นคำอธิบาย deploy เพียงอย่างเดียว

ตารางเทียบสั้นกับ meeting-backoffice (Next)

new (CRA embed)meeting-backoffice (Next)
Path/meeting-backoffice/meetingbo
List loadclient fetchSSG
Token entryไม่มี[token].tsx + X-API-Key
2way Bearertestnajaไม่แนบ
Sentryไม่มีdep มี / init comment
Artifactbuild/ committed + embeddedDocker yarn dev
Env in gitไม่มี.env UAT committed

หมายเหตุเรื่องชื่อที่ทำให้สับสน

ชื่อคืออะไร
meeting-backoffice-newCRA + embed /meeting-backoffice (เอกสารชุดนี้)
meeting-backofficeNext /meetingbo service แยก
2way-meeting-backofficeNext 2way HR/LIFF — ไม่เกี่ยวกับ meeting platform
package name meeting-backoffice ใน repo นี้ตรงหน้าที่ แต่ชนชื่อโฟลเดอร์ Next twin

เมื่อเปิด ticket หรือ PR ให้ระบุ path ที่ผู้ใช้เห็น (/meeting-backoffice vs /meetingbo) ไม่ใช่แค่ชื่อ repo


ขั้นตอน verify หลัง rebuild (สั้น)

  1. npm run build
  2. grep -oE 'https?://[^\" ]*redcross[^\" ]*' build/static/js/main.*.js | head — ต้องเห็น host API จริง
  3. shasum -a 1 build/static/js/main.*.js แล้วเทียบกับไฟล์ใน vtrc-*-backoffice/meeting/ หลัง sync
  4. เปิดหน้า list ใน IDE browser tab ใต้ backoffice origin — ดู Network ว่าไม่ขึ้น undefined/secure

branch canonical ของ twin ทั้งคู่และ backend: UAT / prod-meeting-vtrc-api ตามตาราง workspace — ตรวจก่อน cite

Note

Canonical branches: meeting-backoffice / meeting-backoffice-new = UAT; embed consumers live under vtrc-backoffice*/meeting/ and vtrc-rc-backoffice/meeting/.