การพัฒนาระบบ Session-Based Auth และ REST API จัดการสินค้า

Hashing เป็นการแปลงข้อมูลให้เป็นค่า fixed-length แบบทางเดียว (one-way) ไม่สามารถถอดกลับเป็นข้อมูลเดิมได้ ใช้สำหรับเก็บข้อมูลที่ไม่ต้องนำกลับมาดูค่าจริง เช่น password เพราะแค่ต้องตรวจสอบว่าตรงกันหรือไม่ ตัวอย่าง: bcrypt, SHA-256

Encryption เป็นการเข้ารหัสข้อมูลแบบสองทาง (two-way) สามารถถอดรหัสกลับเป็นข้อมูลเดิมได้ด้วย key ใช้กับข้อมูลที่ต้องนำกลับมาใช้ เช่น เลขบัตรเครดิต, ข้อความใน chat ตัวอย่าง: AES, RSA

สรุป: Password ใช้ Hashing, ข้อมูลที่ต้องถอดกลับใช้ Encryption

Session-based: server สร้าง session id เก็บใน database/memory แล้วส่ง id ผ่าน cookie ให้ client ทุก request client ส่ง id กลับมา server ตรวจกับ store

• ข้อดี: เพิกถอน session ได้ทันที, ข้อมูลผู้ใช้อยู่ฝั่ง server ปลอดภัยกว่า
• ข้อเสีย: ต้องมี state ที่ server, scale แนวนอนต้องใช้ shared store (Redis)

JWT: server เซ็น token ที่บรรจุข้อมูลผู้ใช้แล้วส่งให้ client เก็บ client แนบ token มากับทุก request server แค่ verify signature

• ข้อดี: Stateless, scale ง่าย, ใช้ได้ดีกับ microservices/mobile
• ข้อเสีย: เพิกถอน token ก่อนหมดอายุยาก, ขนาด token ใหญ่กว่า cookie

เมื่อไหร่ใช้แบบไหน: Web app ทั่วไปที่ต้อง logout ทันทีและคุมจำนวน session ใช้ Session-based; ระบบ microservice/mobile/SPA ที่ต้องการ stateless ใช้ JWT

HttpOnly Cookie คือ cookie ที่ JavaScript ฝั่ง client อ่านไม่ได้ (เข้าได้แค่ผ่าน HTTP request เท่านั้น)

หากเก็บ session id หรือ token ใน localStorage หรือ cookie ปกติ ผู้โจมตีที่ทำ XSS สำเร็จจะสามารถอ่านและขโมยไปสวมสิทธิ์ผู้ใช้ได้ทันที

การใช้ HttpOnly ช่วยป้องกัน XSS ไม่ให้ขโมย token ไปได้ และควรใช้คู่กับ Secure (ส่งผ่าน HTTPS เท่านั้น) และ SameSite=Lax/Strict (ป้องกัน CSRF)

SQL Injection คือการโจมตีที่ผู้ใช้แอบแทรกคำสั่ง SQL ผ่าน input เช่น username ปกติคือ admin แต่ผู้โจมตีพิมพ์ admin' OR '1'='1 ถ้าโค้ดต่อ string แบบ "SELECT * FROM users WHERE name='" + input + "'" SQL ที่ได้จะกลายเป็นเงื่อนไขที่จริงเสมอ

ORM (Drizzle, Prisma) ปลอดภัยกว่า เพราะใช้ Parameterized Query / Prepared Statement โดยอัตโนมัติ ค่าที่ส่งเข้าไปจะถูกมองเป็น "ข้อมูล" ไม่ใช่ "คำสั่ง" ฐานข้อมูลจะ escape ให้เอง

นอกจากนี้ ORM ยังมี Type-safety ช่วยให้ TypeScript จับ error ได้ตั้งแต่ตอน compile

CORS (Cross-Origin Resource Sharing) คือกลไกของ browser ที่ป้องกัน script จาก origin หนึ่งไปเรียก resource ที่ origin อื่นโดยอัตโนมัติ (Same-Origin Policy)

Origin ประกอบด้วย scheme + host + port เช่น http://localhost:3000 กับ http://localhost:5000 ถือว่าคนละ origin

เมื่อไหร่ที่ต้องสนใจ:

• Frontend และ Backend อยู่คนละ domain/port (เช่น React อยู่ :3000 API อยู่ :8000)
• Mobile/SPA เรียก API ข้าม domain
• ต้องการให้ส่ง cookie ข้าม origin (ต้องตั้ง Access-Control-Allow-Credentials: true และระบุ origin ชัดเจน ห้ามใช้ *)

ใน Next.js สามารถตั้งใน next.config.ts หรือใน Route Handler โดยเซ็ต header Access-Control-Allow-Origin

การออกแบบ URL: ใช้คำนามพหูพจน์ ไม่ใช้ verb ใน URL

• GET /products - ดึงรายการสินค้าทั้งหมด
• GET /products/:id - ดึงสินค้าตาม id
• POST /products - สร้างสินค้าใหม่
• PUT /products/:id - แทนที่ข้อมูลทั้งก้อน
• PATCH /products/:id - แก้บางฟิลด์
• DELETE /products/:id - ลบสินค้า

HTTP Status Codes ที่ใช้บ่อย:

• 200 OK - สำเร็จทั่วไป (GET, PUT, PATCH)
• 201 Created - สร้างสำเร็จ (POST)
• 204 No Content - สำเร็จและไม่มี body (DELETE)
• 400 Bad Request - input ไม่ถูกต้อง / validation fail
• 401 Unauthorized - ยังไม่ login
• 403 Forbidden - login แล้วแต่ไม่มีสิทธิ์
• 404 Not Found - ไม่พบ resource
• 409 Conflict - ข้อมูลซ้ำ เช่น email ถูกใช้แล้ว
• 500 Internal Server Error - error ฝั่ง server