禁用或删除用户帐户不会触发身份验证状态更改.也不应该，用户仍然经过身份验证.最多一小时后，Firebase 身份验证将尝试刷新用户的访问令牌.刷新将失败，此时用户将变为未经身份验证，并且将触发 auth 状态更改事件.

Disabling or deleting a user account does not fire an auth state change. Nor should it, the user is still authenticated. In at most an hour, Firebase Authentication will try to refresh the access token for the user. That refresh will fail, at which point the user will become unauthenticated and the auth state change event will fire.

如果您想立即撤销用户的授权，则必须在应用程序逻辑的另一部分执行此操作.一种常见的方法是在您的应用程序中设置黑名单，例如在 Firebase 数据库中:

If you're looking to revoke the user's authorization immediately, you will have to do so in another part of your application logic. A common way to do this is by having a blacklist in your application, e.g. in the Firebase Database:

/bannedUsers
    uidOfBannedUser: true

现在，当您在身份验证面板中删除/禁用用户帐户时，您还将其 uid 添加到数据库中的禁止用户列表中.

Now when you delete/disable a user's account in the Autentication panel, you also add their uid to the list of banned users in the database.

然后可以通过在您的数据库安全性中添加子句来保护数据库免受未经授权用户的访问规则，例如

The database can then be secured against access from unauthorized users by adding a clause to your database security rules, e.g.

{
  "rules": {
    "bannedUsers": {
      ".read": true,
      ".write": false // only admins can write these
    },
    "messages": {
      ".read": "auth != null && !root.child('bannedUsers').child(auth.uid).exists()"
    }
  }
}

如果使用不同的后端，实现会有所不同.但是像这样的黑名单是禁止用户的常用方法.您会发现您甚至可能不太关心他们的身份验证，以至于您只是禁止他们，而不是删除他们的凭据(他们可以简单地重新创建).

If you use a different back-end, the implementation will be different. But a blacklist like this is a common approach to ban users. You'll find that you may even care little enough about their authentication that you only ban them, instead of deleting their credentials (which they could simply recreate).