Firestore规则含自定义声明时偶发失效问题排查

看起来你遇到了个挺头疼的间歇性bug——明明iOS客户端已经刷新令牌、确认自定义声明存在，Firestore的权限规则却时不时掉链子，尤其是往那个特定的用户账户路径写数据的时候，失效频率还特别高。这种时好时坏的问题，大多和令牌同步延迟、规则逻辑细节或者客户端缓存有关，我来帮你逐一排查：

1. 先排查令牌同步的时间差问题 #

虽然你在客户端刷新了令牌，但Firebase Auth后端和Firestore服务之间可能存在短暂的同步延迟。自定义声明更新后，Firestore的身份验证系统可能需要几秒到几十秒的时间才能完全识别新的声明，这时候如果客户端急着发请求，就会触发规则失效。

解决办法： #

• 别在刷新令牌后立刻发Firestore请求，加个1-2秒的小延迟，或者监听iOS端Auth的IDTokenDidChange通知，等确认令牌完全更新后再执行写入操作。
• 主动调用currentUser?.getIDTokenResult(completion:)方法，拿到最新的令牌结果，确认里面包含你需要的权限声明后，再发起写入请求，这样更稳妥。

2. 检查Firestore规则的逻辑漏洞 #

你提供的规则片段不完整，但这类间歇性失效经常和规则里的声明检查逻辑有关，比如：

• 是不是写错了声明的名称？比如你在后端设的是stepUpVerified，规则里却写成了stepupverified（大小写敏感哦）。
• 有没有验证请求的用户ID和路径里的用户ID是否一致？比如路径里的z4enRpOt3TXwjUkyD7qsShXTRMF3得和request.auth.uid匹配，不然可能出现权限混淆。
• 是不是误用了request.auth的属性？比如应该用request.auth.token.yourClaim，却写成了request.auth.yourClaim。

给你个参考的规则写法（假设你的自定义声明是hasAdvancedAccess）： #

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/accounts/{accountId} {
      allow write: if request.auth != null 
        && request.auth.uid == userId 
        && request.auth.token.hasAdvancedAccess == true;
    }
  }
}

3. 清理iOS客户端的令牌缓存 #

Firebase Auth在iOS端会缓存令牌，有时候刷新令牌的操作可能没完全覆盖旧缓存，导致Firestore请求还是用了不包含自定义声明的旧令牌。

解决办法： #

• 刷新令牌时，用currentUser?.getIDTokenForcingRefresh(true, completion:)这个方法，强制获取最新的令牌，跳过缓存。
• 如果还是不行，可以试试在验证验证码拿到声明后，先调用Auth.auth().signOut()再重新登录，彻底清掉旧的令牌缓存（这是终极手段，不到万不得已别用）。

4. 排查特定路径的额外规则限制 #

你说失效最频繁的是那个特定路径，得检查：

• 这个路径的父级（比如/users/{userId}）有没有更严格的规则？Firestore的规则是自上而下匹配的，父级规则可能会覆盖子路径的权限。
• 是不是这个文档的现有数据或者客户端写入的字段触发了规则里的字段验证？比如规则要求某个字段必须是数字，但客户端偶尔传了字符串，就会触发权限拒绝。

5. 处理网络波动导致的令牌失效 #

如果客户端网络不稳定，Firestore请求可能会用过期的令牌，或者在令牌同步完成前就发出去了，导致规则校验失败。

解决办法： #

• 在客户端加个重试逻辑：当收到permission-denied错误时，先刷新令牌，再重新发起请求。
• 开启Firebase的离线持久化功能，这样请求在网络恢复后，会用最新的令牌重新执行。

内容的提问来源于stack exchange，提问作者Steve Cox