แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ signInWithRedirect บนเบราว์เซอร์ที่บล็อกการเข้าถึงที่เก็บข้อมูลของบุคคลที่สาม

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

เอกสารนี้อธิบายแนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้การลงชื่อเข้าใช้แบบเปลี่ยนเส้นทางบนเบราว์เซอร์ที่บล็อกคุกกี้ของบุคคลที่สาม

ภาพรวม

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

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

  • หากคุณโฮสต์แอปด้วย Firebase Hosting บนโดเมนย่อยของ firebaseapp.com คุณจะไม่ได้รับผลกระทบจากปัญหานี้และไม่จำเป็นต้องดำเนินการใดๆ
  • หากคุณโฮสต์แอปด้วย Firebase Hosting บนโดเมนที่กำหนดเองหรือโดเมนย่อยของ web.app ให้ใช้ ตัวเลือกที่ 1
  • หากคุณโฮสต์แอปกับบริการอื่นที่ไม่ใช่ Firebase ให้ใช้ ตัวเลือก 2 ตัวเลือก 3 ตัวเลือก 4 หรือ ตัวเลือก 5

ตัวเลือกที่ 1: อัปเดตการกำหนดค่า Firebase เพื่อใช้โดเมนที่กำหนดเองเป็น authDomain

หากคุณโฮสต์แอปด้วย Firebase Hosting โดยใช้โดเมนที่กำหนดเอง คุณสามารถกำหนดค่า Firebase SDK ให้ใช้โดเมนที่กำหนดเองเป็น authDomain สิ่งนี้ทำให้แน่ใจว่าแอพของคุณและ auth iframe ใช้โดเมนเดียวกัน ซึ่งจะป้องกันปัญหาการลงชื่อเข้าใช้ (หากคุณไม่ได้ใช้โฮสติ้ง Firebase คุณต้องใช้ตัวเลือกอื่น)

หากต้องการอัปเดตการกำหนดค่า Firebase เพื่อใช้โดเมนที่กำหนดเองเป็นโดเมนรับรองความถูกต้อง ให้ทำดังต่อไปนี้:

  1. กำหนดค่า Firebase JS SDK เพื่อใช้โดเมนที่คุณกำหนดเองเป็น authDomain :

    const firebaseConfig = {
  apiKey: "<api-key>",
  authDomain: "<the-domain-that-serves-your-app>",
  databaseURL: "<database-url>",
  projectId: "<project-id>",
  appId: "<app-id>"
};

  2. เพิ่ม authDomain ใหม่ลงในรายการ URI การเปลี่ยนเส้นทางที่ได้รับอนุญาตของผู้ให้บริการ OAuth วิธีการดำเนินการนี้จะขึ้นอยู่กับผู้ให้บริการ แต่โดยทั่วไป คุณสามารถปฏิบัติตามส่วน "ก่อนที่คุณจะเริ่มต้น" ในผู้ให้บริการรายใดก็ได้เพื่อดูคำแนะนำที่แน่นอน (เช่น ผู้ให้บริการ Facebook ) URI ที่อัปเดตเพื่ออนุญาตมีลักษณะ https://<the-domain-that-serves-your-app>/__/auth/handler — การต่อท้าย /__/auth/handler มีความสำคัญ

    ในทำนองเดียวกัน หากคุณใช้ผู้ให้บริการ SAML ให้เพิ่ม authDomain ใหม่ไปยัง SAML Assertion Consumer Service (ACS) URL

ตัวเลือกที่ 2: เปลี่ยนเป็น signInWithPopup()

ใช้ signInWithPopup() แทน signInWithRedirect() โค้ดที่เหลือของแอปของคุณยังคงเหมือนเดิม แต่ออบเจกต์ UserCredential จะเรียกข้อมูลต่างกัน

Web version 9

  // Before
  // ==============
  signInWithRedirect(auth, new GoogleAuthProvider());
  // After the page redirects back
  const userCred = await getRedirectResult(auth);

  // After
  // ==============
  const userCred = await signInWithPopup(auth, new GoogleAuthProvider());

Web version 8

  // Before
  // ==============
  firebase.auth().signInWithRedirect(new firebase.auth.GoogleAuthProvider());
  // After the page redirects back
  var userCred = await firebase.auth().getRedirectResult();

  // After
  // ==============
  var userCred = await firebase.auth().signInWithPopup(
      new firebase.auth.GoogleAuthProvider());
```

การลงชื่อเข้าใช้แบบป๊อปอัปไม่เหมาะสำหรับผู้ใช้เสมอไป—อุปกรณ์หรือแพลตฟอร์มจะบล็อกป๊อปอัปในบางครั้ง และความราบรื่นสำหรับผู้ใช้อุปกรณ์เคลื่อนที่ก็น้อยลง หากการใช้ป๊อปอัปเป็นปัญหาสำหรับแอปของคุณ คุณจะต้องปฏิบัติตามหนึ่งในตัวเลือกอื่นๆ

ตัวเลือกที่ 3: พร็อกซีส่งคำขอไปยัง firebaseapp.com

signInWithRedirect เริ่มต้นด้วยการเปลี่ยนเส้นทางจากโดเมนแอปของคุณไปยังโดเมนที่ระบุในพารามิเตอร์ authDomain ในการกำหนดค่า firebase (" .firebaseapp.com" ตามค่าเริ่มต้น) authDomain โฮสต์รหัสตัวช่วยลงชื่อเข้าใช้ที่เปลี่ยนเส้นทางไปยังผู้ให้บริการข้อมูลประจำตัว ซึ่งเมื่อทำสำเร็จ จะเปลี่ยนเส้นทางกลับไปยังโดเมนแอป

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

  1. ตั้งค่าพร็อกซีย้อนกลับบนเซิร์ฟเวอร์แอปของคุณ เพื่อให้คำขอ GET/POST ที่ส่งไปยัง https://<app domain>/__/auth/ ถูกส่งต่อไปยัง https://<project>.firebaseapp.com/__/auth/ ตรวจสอบให้แน่ใจว่าการส่งต่อนี้โปร่งใสต่อเบราว์เซอร์ สิ่งนี้ไม่สามารถทำได้ผ่านการเปลี่ยนเส้นทาง 302

    หากคุณใช้ nginx เพื่อให้บริการโดเมนที่กำหนดเอง การกำหนดค่า reverse-proxy จะมีลักษณะดังนี้:

    # reverse proxy for signin-helpers for popup/redirect sign in.
location /__/auth {
  proxy_pass https://<project>.firebaseapp.com;
}

  2. ทำตามขั้นตอนใน ตัวเลือกที่ 1 เพื่ออัปเดต Authorized redirect_uri , ACS URL และ authDomain ของคุณ เมื่อคุณปรับใช้แอปอีกครั้ง การเข้าถึงพื้นที่เก็บข้อมูลแบบข้ามต้นทางจะไม่เกิดขึ้นอีกต่อไป

ตัวเลือกที่ 4: โฮสต์รหัสผู้ช่วยในการลงชื่อเข้าใช้ด้วยตนเองในโดเมนของคุณ

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

การโฮสต์รหัสผู้ช่วยเหลือมีขั้นตอนดังนี้

  1. ดาวน์โหลดไฟล์ไปยังโฮสต์จากตำแหน่ง <project>.firebaseapp.com โดยดำเนินการคำสั่งต่อไปนี้:

    mkdir signin_helpers/ && cd signin_helpers
wget https://<project>.firebaseapp.com/__/auth/handler
wget https://<project>.firebaseapp.com/__/auth/handler.js
wget https://<project>.firebaseapp.com/__/auth/experiments.js
wget https://<project>.firebaseapp.com/__/auth/iframe
wget https://<project>.firebaseapp.com/__/auth/iframe.js

  2. โฮสต์ไฟล์ด้านบนภายใต้โดเมนแอปของคุณ ตรวจสอบให้แน่ใจว่าเว็บเซิร์ฟเวอร์ของคุณตอบสนองต่อ https://<app domain>/__/auth/<filename>

    นี่คือ ตัวอย่างการใช้งานเซิร์ฟเวอร์ ที่ดาวน์โหลดและโฮสต์ไฟล์

  3. ทำตามขั้นตอนใน ตัวเลือกที่ 1 เพื่ออัปเดต Authorized redirect_uri และ authDomain ของคุณ เมื่อคุณปรับใช้แอปอีกครั้ง การเข้าถึงพื้นที่เก็บข้อมูลแบบข้ามต้นทางจะไม่เกิดขึ้นอีกต่อไป

ตัวเลือกที่ 5: จัดการการลงชื่อเข้าใช้ของผู้ให้บริการโดยอิสระ

Firebase Authentication SDK ให้ signInWithPopup() และ signInWithRedirect() เป็นวิธีอำนวยความสะดวกในการรวมตรรกะที่ซับซ้อนและหลีกเลี่ยงความจำเป็นในการเกี่ยวข้องกับ SDK อื่น คุณสามารถหลีกเลี่ยงการใช้วิธีใดวิธีหนึ่งโดยสิ้นเชิงได้โดยการลงชื่อเข้าใช้ผู้ให้บริการของคุณโดยอิสระ จากนั้นใช้ signInWithCredential() เพื่อแลกเปลี่ยนข้อมูลรับรองของผู้ให้บริการเป็นข้อมูลรับรองการตรวจสอบสิทธิ์ของ Firebase ตัวอย่างเช่น คุณสามารถใช้ Google Sign In SDK ซึ่งเป็น โค้ดตัวอย่าง เพื่อรับข้อมูลรับรองบัญชี Google จากนั้นสร้างตัวอย่างข้อมูลรับรอง Google ใหม่โดยเรียกใช้โค้ดต่อไปนี้:

Web version 9

  // `googleUser` from the onsuccess Google Sign In callback.
  //  googUser = gapi.auth2.getAuthInstance().currentUser.get();
  const credential = GoogleAuthProvider.credential(googleUser.getAuthResponse().id_token);
  const result = await signInWithCredential(auth, credential);

Web version 8

  // `googleUser` from the onsuccess Google Sign In callback.
  const credential = firebase.auth.GoogleAuthProvider.credential(
      googleUser.getAuthResponse().id_token);
  const result = await firebase.auth().signInWithCredential(credential);

หลังจากที่คุณเรียก signInWithCredential() แล้ว แอปที่เหลือจะทำงานเหมือนเดิม

คำแนะนำในการรับข้อมูลประจำตัวของ Apple อยู่ ที่นี่