ผู้ใช้ในโครงการ Firebase

ออบเจ็กต์ ผู้ใช้ Firebase แสดงถึงบัญชีผู้ใช้ที่ได้สมัครใช้งานแอปในโครงการของคุณ แอพมักจะมีผู้ใช้ที่ลงทะเบียนจำนวนมาก และทุกแอพในโปรเจ็กต์จะแชร์ฐานข้อมูลผู้ใช้

อินสแตนซ์ผู้ใช้ไม่ขึ้นอยู่กับอินสแตนซ์ Firebase Authentication ดังนั้นคุณจึงสามารถมีการอ้างอิงหลายรายการไปยังผู้ใช้ที่แตกต่างกันภายในบริบทเดียวกัน และยังคงเรียกใช้เมธอดใดๆ ของพวกเขาได้

คุณสมบัติผู้ใช้

ผู้ใช้ Firebase มีชุดคุณสมบัติพื้นฐานที่ตายตัว ได้แก่ รหัสที่ไม่ซ้ำกัน ที่อยู่อีเมลหลัก ชื่อ และ URL รูปภาพ ซึ่งจัดเก็บไว้ในฐานข้อมูลผู้ใช้ของโปรเจ็กต์ ซึ่งผู้ใช้สามารถอัปเดตได้ ( iOS , Android , เว็บ ) คุณไม่สามารถเพิ่มคุณสมบัติอื่นให้กับวัตถุผู้ใช้ได้โดยตรง แต่คุณสามารถจัดเก็บคุณสมบัติเพิ่มเติมไว้ในบริการจัดเก็บข้อมูลอื่น ๆ แทน เช่น Google Cloud Firestore

ครั้งแรกที่ผู้ใช้ลงชื่อสมัครใช้แอปของคุณ ข้อมูลโปรไฟล์ของผู้ใช้จะถูกเติมโดยใช้ข้อมูลที่มีอยู่:

  • หากผู้ใช้ลงทะเบียนด้วยที่อยู่อีเมลและรหัสผ่าน ระบบจะเติมเฉพาะคุณสมบัติที่อยู่อีเมลหลักเท่านั้น
  • หากผู้ใช้ลงทะเบียนกับผู้ให้บริการข้อมูลประจำตัวแบบรวมศูนย์ เช่น Google หรือ Facebook ข้อมูลบัญชีที่ผู้ให้บริการให้ไว้จะถูกนำมาใช้เพื่อเติมโปรไฟล์ของผู้ใช้
  • หากผู้ใช้ลงทะเบียนกับระบบการตรวจสอบสิทธิ์ที่กำหนดเองของคุณ คุณต้องเพิ่มข้อมูลที่คุณต้องการลงในโปรไฟล์ของผู้ใช้อย่างชัดเจน

เมื่อสร้างบัญชีผู้ใช้แล้ว คุณสามารถโหลดข้อมูลผู้ใช้ซ้ำเพื่อรวมการเปลี่ยนแปลงใดๆ ที่ผู้ใช้อาจทำบนอุปกรณ์อื่นได้

ผู้ให้บริการลงชื่อเข้าใช้

คุณสามารถลงชื่อเข้าใช้แอปของคุณให้ผู้ใช้ได้หลายวิธี ได้แก่ ที่อยู่อีเมลและรหัสผ่าน ผู้ให้บริการข้อมูลประจำตัวแบบรวมศูนย์ และระบบการตรวจสอบสิทธิ์ที่กำหนดเองของคุณ คุณสามารถเชื่อมโยงวิธีการลงชื่อเข้าใช้กับผู้ใช้ได้มากกว่าหนึ่งวิธี เช่น ผู้ใช้สามารถลงชื่อเข้าใช้บัญชีเดียวกันโดยใช้ที่อยู่อีเมลและรหัสผ่าน หรือใช้ Google Sign-In

อินสแตนซ์ผู้ใช้ติดตามผู้ให้บริการทุกรายที่เชื่อมโยงกับผู้ใช้ วิธีนี้ช่วยให้คุณสามารถอัปเดตคุณสมบัติของโปรไฟล์ที่ว่างเปล่าโดยใช้ข้อมูลที่ผู้ให้บริการให้ไว้ โปรดดูการจัดการผู้ใช้ ( iOS , Android , เว็บ )

ผู้ใช้ปัจจุบัน

เมื่อผู้ใช้ลงทะเบียนหรือลงชื่อเข้าใช้ ผู้ใช้นั้นจะกลายเป็นผู้ใช้ปัจจุบันของอินสแตนซ์ Auth อินสแตนซ์จะคงสถานะของผู้ใช้ไว้ ดังนั้นการรีเฟรชเพจ (ในเบราว์เซอร์) หรือการรีสตาร์ทแอปพลิเคชันจะไม่ทำให้ข้อมูลของผู้ใช้สูญหาย

เมื่อผู้ใช้ออกจากระบบ อินสแตนซ์ Auth จะหยุดเก็บการอ้างอิงไปยังออบเจ็กต์ผู้ใช้และไม่คงสถานะไว้อีกต่อไป ไม่มีผู้ใช้ปัจจุบัน อย่างไรก็ตาม อินสแตนซ์ผู้ใช้ยังคงทำงานได้อย่างสมบูรณ์: หากคุณใช้การอ้างอิงอินสแตนซ์ดังกล่าว คุณยังคงสามารถเข้าถึงและอัปเดตข้อมูลของผู้ใช้ได้

วงจรการใช้งานของผู้ใช้

วิธีที่แนะนำในการติดตามสถานะปัจจุบันของอินสแตนซ์ Auth คือการใช้ Listener (หรือที่เรียกว่า "ผู้สังเกตการณ์" ใน JavaScript) ผู้ฟัง Auth จะได้รับแจ้งทุกครั้งที่มีสิ่งที่เกี่ยวข้องเกิดขึ้นกับออบเจ็กต์ Auth โปรดดูการจัดการผู้ใช้ ( iOS , Android , เว็บ )

ผู้ฟัง Auth จะได้รับการแจ้งเตือนในสถานการณ์ต่อไปนี้:

  • ออบเจ็กต์การรับรองความถูกต้องเสร็จสิ้นการเริ่มต้นและผู้ใช้ได้ลงชื่อเข้าใช้จากเซสชันก่อนหน้าแล้ว หรือถูกเปลี่ยนเส้นทางจากขั้นตอนการลงชื่อเข้าใช้ของผู้ให้บริการข้อมูลประจำตัว
  • ผู้ใช้ลงชื่อเข้าใช้ (ตั้งค่าผู้ใช้ปัจจุบันแล้ว)
  • ผู้ใช้ออกจากระบบ (ผู้ใช้ปัจจุบันกลายเป็นโมฆะ)
  • รีเฟรชโทเค็นการเข้าถึงของผู้ใช้ปัจจุบันแล้ว กรณีนี้สามารถเกิดขึ้นได้ภายใต้เงื่อนไขดังต่อไปนี้:
    • โทเค็นการเข้าถึงหมดอายุ: นี่เป็นสถานการณ์ทั่วไป โทเค็นการรีเฟรชใช้เพื่อรับชุดโทเค็นที่ถูกต้องใหม่
    • ผู้ใช้เปลี่ยนรหัสผ่าน: Firebase ออกการเข้าถึงใหม่และโทเค็นการรีเฟรช และทำให้โทเค็นเก่าหมดอายุ การทำเช่นนี้จะทำให้โทเค็นของผู้ใช้หมดอายุโดยอัตโนมัติและ/หรือออกจากระบบผู้ใช้ในทุกอุปกรณ์ ด้วยเหตุผลด้านความปลอดภัย
    • ผู้ใช้ตรวจสอบสิทธิ์อีกครั้ง: การดำเนินการบางอย่างกำหนดให้ต้องออกข้อมูลรับรองของผู้ใช้เมื่อเร็วๆ นี้ การกระทำดังกล่าวรวมถึงการลบบัญชี การตั้งค่าที่อยู่อีเมลหลัก และการเปลี่ยนรหัสผ่าน แทนที่จะออกจากระบบผู้ใช้แล้วลงชื่อเข้าใช้ผู้ใช้อีกครั้ง ให้รับข้อมูลรับรองใหม่จากผู้ใช้ และส่งต่อข้อมูลรับรองใหม่ไปยังวิธีการตรวจสอบสิทธิ์ซ้ำของออบเจ็กต์ผู้ใช้

ผู้ใช้บริการตนเอง

ตามค่าเริ่มต้น Firebase จะอนุญาตให้ผู้ใช้ลงชื่อสมัครใช้และลบบัญชีของตนโดยไม่ต้องมีการแทรกแซงจากผู้ดูแลระบบ ในหลาย ๆ สถานการณ์ สิ่งนี้ช่วยให้ผู้ใช้ปลายทางสามารถค้นพบแอปพลิเคชันหรือบริการของคุณและบนเครื่อง (หรือนอกเครื่อง) โดยมีแรงเสียดทานน้อยที่สุด

อย่างไรก็ตาม มีบางสถานการณ์ที่คุณต้องการให้ผู้ดูแลระบบสร้างผู้ใช้ด้วยตนเองหรือโดยทางโปรแกรม โดยใช้ Admin SDK หรือคอนโซล Firebase ในกรณีเหล่านี้ คุณสามารถปิดใช้การดำเนินการของผู้ใช้ได้จากหน้า การตั้งค่าการตรวจสอบสิทธิ์ Firebase ซึ่งจะป้องกันการสร้างและการลบบัญชีโดยผู้ใช้ปลายทาง หากคุณใช้ผู้เช่าหลายราย คุณจะต้องส่งคำขอ HTTP เพื่อปิดใช้งาน คุณลักษณะเหล่านี้ตามผู้เช่าแต่ละราย

หากผู้ใช้พยายามสร้างหรือลบบัญชีภายในระบบของคุณ บริการ Firebase จะส่งคืนรหัสข้อผิดพลาด: auth/admin-restricted-operation สำหรับการเรียก Web API หรือ ERROR_ADMIN_RESTRICTED_OPERATION สำหรับ Android และ iOS คุณควรจัดการข้อผิดพลาดในส่วนหน้าของคุณอย่างสวยงามโดยขอให้ผู้ใช้ดำเนินการที่เหมาะสมสำหรับบริการของคุณ

โทเค็นการตรวจสอบสิทธิ์

เมื่อคุณดำเนินการตรวจสอบสิทธิ์กับ Firebase คุณอาจพบโทเค็นการตรวจสอบสิทธิ์สามประเภท:

โทเค็นรหัส Firebase สร้างโดย Firebase เมื่อผู้ใช้ลงชื่อเข้าใช้แอป โทเค็นเหล่านี้ได้รับการลงนาม JWT ซึ่งระบุผู้ใช้ในโครงการ Firebase อย่างปลอดภัย โทเค็นเหล่านี้มีข้อมูลโปรไฟล์พื้นฐานสำหรับผู้ใช้ รวมถึงสตริง ID ของผู้ใช้ ซึ่งเป็นข้อมูลเฉพาะของโปรเจ็กต์ Firebase เนื่องจาก สามารถตรวจสอบความสมบูรณ์ของโทเค็น ID ได้ คุณจึงสามารถส่งโทเค็นไปยังเซิร์ฟเวอร์แบ็กเอนด์เพื่อระบุผู้ใช้ที่ลงชื่อเข้าใช้ในปัจจุบันได้
โทเค็นของผู้ให้บริการข้อมูลประจำตัว สร้างโดยผู้ให้บริการข้อมูลประจำตัวแบบรวมศูนย์ เช่น Google และ Facebook โทเค็นเหล่านี้อาจมีรูปแบบที่แตกต่างกัน แต่มักจะเป็นโทเค็นการเข้าถึง OAuth 2.0 แอปใช้โทเค็นเหล่านี้เพื่อตรวจสอบว่าผู้ใช้ได้ตรวจสอบสิทธิ์กับผู้ให้บริการข้อมูลประจำตัวเรียบร้อยแล้ว จากนั้นแปลงเป็นข้อมูลรับรองที่บริการ Firebase ใช้งานได้
โทเค็นที่กำหนดเองของ Firebase สร้างโดยระบบการตรวจสอบสิทธิ์ที่กำหนดเองของคุณเพื่อให้ผู้ใช้สามารถลงชื่อเข้าใช้แอปโดยใช้ระบบการตรวจสอบสิทธิ์ของคุณ โทเค็นที่กำหนดเองคือ JWT ที่ลงนามโดยใช้รหัสส่วนตัวของบัญชีบริการ แอพใช้โทเค็นเหล่านี้เหมือนกับที่ใช้โทเค็นที่ส่งคืนจากผู้ให้บริการข้อมูลประจำตัวแบบรวมศูนย์

ที่อยู่อีเมลที่ยืนยันแล้ว

Firebase จะถือว่าอีเมลได้รับการยืนยันหากตรงตามเงื่อนไข 2 ประการ:

  1. ผู้ใช้ทำขั้นตอนการยืนยัน Firebase เสร็จสมบูรณ์
  2. อีเมลได้รับการตรวจสอบโดยผู้ให้บริการข้อมูลประจำตัวที่เชื่อถือได้ หรือเรียกสั้นๆ ว่า IdP

IdP ที่ยืนยันอีเมลเพียงครั้งเดียว แต่อนุญาตให้ผู้ใช้เปลี่ยนที่อยู่อีเมลโดยไม่ต้องมีการยืนยันอีกครั้งนั้นไม่น่าเชื่อถือ IdP ที่เป็นเจ้าของโดเมนหรือต้องมีการยืนยันอยู่เสมอจะถือว่าเชื่อถือได้

ผู้ให้บริการที่เชื่อถือได้:

  • Google (สำหรับที่อยู่ @gmail.com)
  • Yahoo (สำหรับที่อยู่ @yahoo.com)
  • Microsoft (สำหรับที่อยู่ @outlook.com และ @hotmail.com)
  • Apple (ตรวจสอบเสมอ เนื่องจากบัญชีได้รับการตรวจสอบและรับรองความถูกต้องด้วยหลายปัจจัยเสมอ)

ผู้ให้บริการที่ไม่น่าเชื่อถือ:

  • เฟสบุ๊ค
  • ทวิตเตอร์
  • GitHub
  • Google, Yahoo และ Microsoft สำหรับโดเมนที่ไม่ได้ออกโดยผู้ให้บริการข้อมูลประจำตัวนั้น
  • อีเมล / รหัสผ่านโดยไม่ต้องยืนยันอีเมล

ในบางสถานการณ์ Firebase จะเชื่อมโยงบัญชีโดยอัตโนมัติเมื่อผู้ใช้ลงชื่อเข้าใช้กับผู้ให้บริการหลายรายโดยใช้ที่อยู่อีเมลเดียวกัน อย่างไรก็ตาม สิ่งนี้สามารถเกิดขึ้นได้เมื่อตรงตามเกณฑ์ที่กำหนดเท่านั้น เพื่อทำความเข้าใจสาเหตุ ให้พิจารณาสถานการณ์ต่อไปนี้: ผู้ใช้ลงชื่อเข้าใช้ Google ด้วยบัญชี @gmail.com และผู้ไม่หวังดีสร้างบัญชีโดยใช้ที่อยู่ @gmail.com เดียวกัน แต่ลงชื่อเข้าใช้ผ่าน Facebook หากทั้งสองบัญชีเชื่อมโยงกันโดยอัตโนมัติ ผู้ประสงค์ร้ายจะสามารถเข้าถึงบัญชีของผู้ใช้ได้

กรณีต่อไปนี้จะอธิบายเมื่อเราเชื่อมโยงบัญชีโดยอัตโนมัติ และเมื่อเราเกิดข้อผิดพลาดที่กำหนดให้ผู้ใช้หรือนักพัฒนาดำเนินการ:

  • ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่น่าเชื่อถือ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการรายอื่นที่ไม่น่าเชื่อถือด้วยอีเมลเดียวกัน (เช่น Facebook ตามด้วย GitHub) สิ่งนี้ทำให้เกิดข้อผิดพลาดที่ต้องมีการลิงก์บัญชี
  • ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่น่าเชื่อถือด้วยอีเมลเดียวกัน (เช่น Google ตามด้วย Facebook) สิ่งนี้ทำให้เกิดข้อผิดพลาดที่ต้องมีการลิงก์บัญชี
  • ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่ไม่น่าเชื่อถือ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้ด้วยอีเมลเดียวกัน (เช่น Facebook ตามด้วย Google) ผู้ให้บริการที่เชื่อถือได้จะเขียนทับผู้ให้บริการที่ไม่น่าเชื่อถือ หากผู้ใช้พยายามลงชื่อเข้าใช้อีกครั้งด้วย Facebook จะทำให้เกิดข้อผิดพลาดในการเชื่อมโยงบัญชี
  • ผู้ใช้ลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้ จากนั้นลงชื่อเข้าใช้ด้วยผู้ให้บริการที่เชื่อถือได้รายอื่นด้วยอีเมลเดียวกัน (เช่น Apple ตามด้วย Google) ผู้ให้บริการทั้งสองจะเชื่อมโยงกันโดยไม่มีข้อผิดพลาด

คุณสามารถตั้งค่าอีเมลให้ได้รับการยืนยันด้วยตนเองได้โดยใช้ Admin SDK แต่เราขอแนะนำให้ทำเช่นนี้เฉพาะเมื่อคุณรู้ว่าผู้ใช้เป็นเจ้าของอีเมลจริงๆ