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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ออบเจกต์ 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 จะพิจารณาอีเมลที่ได้รับการยืนยันหากตรงตามเงื่อนไขสองข้อ:

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