Refactoring NestJS Auth: เพิ่ม Username และ GitHub OAuth
เจาะลึกการรีแฟคเตอร์ระบบยืนยันตัวตน NestJS ที่สร้างด้วย brkpt-auth โดยเพิ่มฟิลด์ username และรองรับ GitHub OAuth พร้อมจัดการตาราง LinkedAccount
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เพิ่มฟิลด์ username เพื่อใช้เป็นตัวระบุตัวตนร่วมกับอีเมล
- สร้างตาราง LinkedAccount เพื่อเชื่อมโยงบัญชี OAuth หลายผู้ให้บริการ
- ติดตั้ง GitHubOAuthDriver เพิ่มเติมเพื่อรองรับการเข้าสู่ระบบผ่าน GitHub
- คงความเรียบร้อยโดยไม่ต้องแก้ไขไฟล์ภายในของ brkpt-auth เลย
หลังจากที่บทความก่อนหน้าได้สร้าง Minimum Viable Product (MVP) สำหรับการเข้าสู่ระบบด้วยรหัสผ่านและ Google Sign-in โดยใช้ brkpt-auth ไปแล้ว บทความล่าสุดนี้ได้นำโปรเจกต์เดิมมาทำการเปลี่ยนแปลงสำคัญสองส่วนด้วยกัน ซึ่งเป็นสิ่งที่จะเกิดขึ้นตามธรรมชาติเมื่อผลิตภัณฑ์เติบโตขึ้น ได้แก่ การเพิ่มฟิลด์ชื่อผู้ใช้ (username) และการรองรับผู้ให้บริการ OAuth รายที่สองอย่าง GitHub
ในส่วนของการเพิ่มฟิลด์ username นั้น ระบบต้องการชื่อที่สาธารณะและไม่ซ้ำใคร เพื่อให้ผู้ใช้งานสามารถแชร์และค้นหาได้ง่าย โดยไม่ผูกติดอยู่กับอีเมลที่อาจเปลี่ยนแปลงภายหลังได้ โดยอีเมลยังคงใช้งานสำหรับการเข้าสู่ระบบได้เช่นเดิม แต่ช่องทางข้อมูล credentials ได้ถูกออกแบบมาสำหรับการใช้ username และรหัสผ่านเป็นหลัก ขณะที่การใช้อีเมลเป็นตัวระบุตัวตนในตอนแรกทำไปเพื่อความสะดวกเท่านั้น อย่างไรก็ตาม การเก็บอีเมลโดยไม่มีการยืนยันตัวตน (Verify-email) อาจสร้างช่องโหว่ความปลอดภัยเมื่อใช้งานร่วมกับ OAuth หากมีคนสมัครด้วยอีเมลคนอื่น
การเพิ่มฟิลด์ข้อมูลสำคัญเช่น username ลงในฐานข้อมูลที่มีผู้ใช้งานอยู่แล้ว ไม่สามารถรัน Migration ตรงๆ ได้ทันที เนื่องจากข้อมูลแถวเดิมไม่มีคอลัมน์นี้รองรับ ในบทความนี้จึงเลือกใช้วิธีรีเซ็ตฐานข้อมูลเพื่อมุ่งเน้นไปที่การปรับเปลี่ยน Adapter เป็นหลัก ขณะที่ในระบบจริง นักพัฒนาจำเป็นต้องมีแผนการ Backfill ข้อมูลเก่าก่อนเสมอ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สำหรับการเปลี่ยนแปลงด้าน OAuth ในตอนแรก ระบบใช้เมลเป็นตัวระบุตัวตนร่วมกัน ซึ่งอาจทำให้เกิดปัญหาเมื่อผู้ใช้อีเมลเดิมเปลี่ยนไปสมัครบัญชีใหม่โดยไม่ได้ตั้งใจหากมีการเปลี่ยนอีเมล แนวทางแก้ไขที่ได้มาตรฐานคือการสร้างตารางแยกต่างหากที่เรียกว่า LinkedAccount ซึ่งทำให้บัญชีผู้ใช้หนึ่งบัญชีสามารถเชื่อมโยงกับ OAuth Provider ได้หลายรายอย่างอิสระ ไม่ขึ้นกับอีเมลในระบบขณะนั้น
เมื่อมีตาราง LinkedAccount รองรับแล้ว การเพิ่มผู้ให้บริการรายที่สองจึงทำได้ง่ายขึ้นมาก โดยใช้คำสั่ง brkpt auth add oauth --driver github เพื่อติดตั้ง GithubOAuthDriver ซึ่งจะทำงานผ่านโปรโตคอลการแลกเปลี่ยน Authorization Code เป็น Access Token แล้วเรียกไปยัง endpoint /user ของ GitHub เพื่อรับข้อมูล JSON กลับมา
"Two real requirements, three adapters, two DTOs, and one new table touched, zero files owned by brkpt-auth edited."
Brkpt
หากเปรียบเทียบกับการพัฒนาสิทธิ์การเข้าใช้งานด้วยตนเองโดยใช้ Passport นักพัฒนาจะต้องจัดการกับส่วนประกอบจำนวนมาก เช่น LocalStrategy, JwtStrategy, JwtRefreshStrategy, GoogleStrategy, GithubStrategy รวมถึง Guard และ AuthService ต่างๆ แต่การใช้เครื่องมือสำเร็จรูปช่วยให้ตรรกะทางธุรกิจยังคงอยู่ภายใน Adapter ที่เราควบคุมเอง โดยไม่ต้องกังวลกับความซับซ้อนของ Service หรือ Controller ที่ถูกสร้างขึ้นมา
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น