Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

ผู้ใช้ในโครงการ 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 แต่เราแนะนำให้ทำเช่นนี้ก็ต่อเมื่อคุณรู้ว่าผู้ใช้เป็นเจ้าของอีเมลจริงๆ