Firebase 電子郵件/密碼身份驗證 + 驗證怪異

Question

對於在用戶開始使用服務之前絕對需要電子郵件驗證的服務，使用電子郵件驗證 + 電子郵件/密碼身份驗證不太適用。

讓我先用一個谷歌登錄的例子來解釋。

首先，用戶op@op.com他們的 Google 帳戶（假設電子郵件是op@op.com ），並授權您的應用程序。 然后您使用通過它收到的令牌創建一個憑證，並與 Firebase 交換這些令牌以將用戶登錄到 Firebase。 用戶需要存在於 Firebase 中才能使用 Firebase 的電子郵件驗證服務（因為獲取有關電子郵件是否已驗證的信息的唯一方法是檢查客戶端中的currentUser對象，因此您需要一個登錄用戶來檢查是否他們的電子郵件已通過驗證。您無法使用電子郵件地址調用Auth方法來檢查它是否已驗證）。 因此，一旦您將用戶登錄到 Firebase，您就向他們發送了一個驗證鏈接，一切都很好。 您可以通過檢查電子郵件驗證的用戶對象來配置客戶端上的視圖。 這里需要注意的重要一點是，一些知道此用戶電子郵件地址的其他用戶無法在您的服務上使用op@op.com進行注冊：這是因為他們需要使用該電子郵件登錄 Google 才能注冊。

在這方面，Facebook 類似於 Google 登錄。

但是，對於 email/password ，任何人都可以使用別人的電子郵件並用它創建一個帳戶！ 由於您無法在用戶注冊 Firebase 之前發送驗證鏈接，因此您實際上是在讓世界上的任何人“阻止”您服務中的電子郵件地址。 我最初試圖在電子郵件注冊到 Firebase 之前確保電子郵件驗證，但很快意識到我需要 Firebase 中的用戶進行任何電子郵件驗證。

我錯過了什么，還是這是預期的行為？ 如果這真的是它的工作原理，那么我可能只是不允許在我的應用程序中使用電子郵件/密碼登錄。

旁注：我的另一個想法是通過向他們發送 6 位代碼來進行驗證，並在 Firebase 中維護我自己的驗證系統。 但是我無法向它添加任何安全規則，因為任何沒有登錄用戶的客戶端都需要訪問它 ==> 潛在的系統濫用。

預先感謝您嘗試通讀冗長的解釋。

Answer 1

因此，即使可以在未經驗證的情況下創建帳戶，您仍然可以使用安全規則阻止用戶訪問。 后者是重要的並控制訪問。 以下是如何使用實時數據庫規則執行此操作的示例：

{
  "rules": {
    "users": {
      "$user": {
        ".read": "auth.token.email_verified == true && auth.uid === $user",
        ".write": "auth.token.email_verified == true && auth.uid === $user"
      }
    }
  }
}

如果您通過解析令牌有效負載並檢查email_verified來驗證服務器上的 ID 令牌，您也可以自行執行此email_verified 。

因此，即使創建了用戶帳戶，除非用戶經過驗證，否則他們將無法訪問您的應用程序/站點數據。