ผู้ใช้ในโปรเจ็กต์ Firebase

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

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

พร็อพเพอร์ตี้ผู้ใช้

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

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

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

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

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

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

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

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

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

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

วงจรผู้ใช้

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

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

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

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

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

แต่ก็มีบางกรณี ที่คุณต้องการให้ผู้ใช้ดำเนินการด้วยตนเอง หรือ เขียนโปรแกรมโดยผู้ดูแลระบบ ไม่ว่าจะใช้ Admin SDK หรือ คอนโซล Firebase ในกรณีเหล่านี้ คุณสามารถปิดใช้การดำเนินการของผู้ใช้ จากการตั้งค่า Firebase Authentication ซึ่งจะป้องกันไม่ให้ผู้ใช้ปลายทางสร้างและลบบัญชี หากใช้กลุ่มผู้ใช้หลายกลุ่ม คุณจะต้องส่งคำขอ 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 (ยืนยันเสมอเนื่องจากบัญชีได้รับการยืนยันและตรวจสอบสิทธิ์แบบหลายปัจจัยเสมอ)

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

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

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

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

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

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