Catch up on everthing we announced at this year's Firebase Summit. Learn more

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วงจรชีวิตผู้ใช้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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