Flutter集成Firebase Vertex AI含Storage URL触发权限错误排查

问题重现 #

• Flutter 3.22.0应用使用firebase_vertexai 0.1.0+1 SDK，仅使用文本提示时功能正常，但传入Firebase Storage URL后触发The caller does not have permission错误
• 将Storage安全规则改为allow read, write: if true可临时解决问题，但此规则会完全开放存储桶权限，存在严重安全风险
• 尝试过的无效方案：
  • 配置包含多个服务账号邮箱的严格安全规则
  • 为多个关联服务账号授予Cloud Storage for Firebase Admin角色

相关核心代码：

Stream<String?> generateTextFromMediaStream(String promptText, List<String>? mediaPaths) async* {
    
      final prompt = TextPart(promptText);
      List mediaPartsFuture = [];
      if (mediaPaths != null) {
        mediaPartsFuture = mediaPaths.map((path)  {
          final mimeType = getMimeType(path);
          return FileData(mimeType, path);

        }).toList();
      
      }

      final response = _model.generateContentStream([
        Content.multi([prompt, ...mediaPartsFuture])
      ]);

      await for (final chunk in response) {
        yield chunk.text;
      }
  }

问题核心原因 #

Vertex AI服务端调用Firebase Storage时，不会携带用户身份信息（request.auth为空），且并非通过你列出的服务账号发起请求，而是使用Google内部的服务身份访问。常规安全规则中基于request.auth或服务账号邮箱的匹配逻辑无法覆盖这种场景，导致权限验证失败。

安全解决方案 #

方案1：使用签名URL替代直接存储路径 #

在客户端生成Storage文件的临时签名URL，将该URL传给Vertex AI。签名URL自带权限验证，无需修改原有严格的Storage安全规则。

修改后的代码示例：

import 'package:firebase_storage/firebase_storage.dart';

Stream<String?> generateTextFromMediaStream(String promptText, List<String>? mediaPaths) async* {
  final prompt = TextPart(promptText);
  List<FileData> mediaParts = [];
  
  if (mediaPaths != null) {
    for (final path in mediaPaths) {
      final ref = FirebaseStorage.instance.ref(path);
      // 生成有效期1小时的签名URL（可根据需求调整时长）
      final signedUrl = await ref.getSignedUrl(
        const SettableMetadata(),
        const Duration(hours: 1),
      );
      final mimeType = getMimeType(path);
      mediaParts.add(FileData(mimeType, signedUrl));
    }
  }

  final response = _model.generateContentStream([
    Content.multi([prompt, ...mediaParts])
  ]);

  await for (final chunk in response) {
    yield chunk.text;
  }
}

如果需要长期可访问的URL（仍受安全规则控制），也可以用await ref.getDownloadURL()替代签名URL生成逻辑。

方案2：针对性放宽Storage安全规则 #

如果不想使用签名URL，可以通过识别请求来源，仅对特定路径的媒体文件开放权限，而非全局开放：

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    // 仅允许GCP服务访问指定的媒体文件路径
    match /ai-media/{allPaths=**} {
      allow read: if request.auth == null && 
                   request.headers['x-goog-request-source'] == 'GCP';
    }
    // 其他路径保持原有严格的身份验证规则
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

此规则通过x-goog-request-source请求头判断是否为GCP内部服务发起的请求，同时限制仅ai-media路径下的文件可被访问，兼顾安全性和功能需求。

方案3：通过Cloud Functions中转处理 #

将媒体文件的读取和Vertex AI调用逻辑放在Cloud Functions中，客户端仅调用Functions接口。这种方式完全隔离客户端与Storage、Vertex AI的权限交互，安全性最高，但需要额外开发中转函数。

验证步骤 #

1. 部署修改后的代码或安全规则
2. 测试带媒体文件的生成请求，确认权限错误消失
3. 查看Firebase Storage控制台的访问日志，验证只有合法请求被允许

内容的提问来源于stack exchange，提问作者Oscar Caicedo