Vue结合Firebase如何设置uploadProduct页面仅管理员可访问

你构思的路由守卫+校验登录用户邮箱的方案仅适合本地临时测试，生产环境使用存在明显安全隐患：前端的路由校验可以被用户通过浏览器控制台篡改路由、伪造本地用户信息轻松绕过，且硬编码管理员邮箱后续维护成本极高。以下是按推荐优先级排序的可落地方案：

方案1：Firebase自定义声明（Custom Claims，生产环境首选） #

这是Firebase官方推荐的角色权限实现方案，权限标记存储在用户的身份令牌中，由Firebase服务端签发，前端无法篡改，同时可直接被Firestore、Storage等服务的安全规则读取，实现前后端双重校验。
实现步骤：

1. 服务端配置管理员标记
   不要在前端代码里操作权限赋值，通过Firebase Admin SDK（可搭配Cloud Functions运行，或在你自己的可信服务端环境执行）给指定用户添加管理员声明，示例代码：

   // 仅在服务端运行，严禁暴露到前端
   const { getAuth } = require("firebase-admin/auth");
   // 替换为实际要授予管理员权限的用户uid
   getAuth().setCustomUserClaims("目标用户UID", { admin: true });
   

2. 前端路由守卫校验
   给需要管理员权限的路由添加meta标记，在beforeEach守卫中等待认证状态稳定后，解析用户令牌中的声明判断权限，以Vue Router 4.x为例：

   // router/index.js
   import { createRouter, createWebHistory } from "vue-router";
   import { getAuth, onAuthStateChanged } from "firebase/auth";
   
   const routes = [
     // 其他路由...
     {
       path: "/uploadProduct",
       component: () => import("../views/UploadProduct.vue"),
       // 标记该路由需要登录+管理员权限
       meta: { requiresAuth: true, requiresAdmin: true }
     }
   ];
   
   const router = createRouter({
     history: createWebHistory(),
     routes
   });
   
   router.beforeEach(async (to, from, next) => {
     const requiresAdmin = to.matched.some(record => record.meta.requiresAdmin);
     // 不需要管理员权限的路由直接放行
     if (!requiresAdmin) return next();
   
     const auth = getAuth();
     // 等待认证状态初始化完成，避免刷新页面时auth状态还没加载就误判
     const currentUser = await new Promise(resolve => {
       const unsubscribe = onAuthStateChanged(auth, user => {
         unsubscribe();
         resolve(user);
       });
     });
   
     // 未登录跳转到登录页
     if (!currentUser) return next("/login");
   
     // 解析用户令牌拿到自定义声明
     const tokenResult = await currentUser.getIdTokenResult();
     if (tokenResult.claims.admin) {
       return next(); // 管理员放行
     } else {
       return next("/403"); // 无权限跳转到403提示页
     }
   });
   
   export default router;
   

3. 配置服务端安全规则（必做，防绕过核心）
   前端的所有校验都只能做交互层面的拦截，必须在Firebase安全规则层面限制非管理员的写操作，从根源阻止非法上传，Firestore规则示例：

   rules_version = '2';
   service cloud.firestore {
     match /databases/{database}/documents {
       // 产品数据集合：所有用户可读，仅管理员可写
       match /products/{productId} {
         allow read: if true;
         allow write: if request.auth != null && request.auth.token.admin == true;
       }
       // 管理员集合禁止普通用户访问
       match /admins/{any=**} {
         allow read, write: if request.auth != null && request.auth.token.admin == true;
       }
     }
   }
   

   注意：给用户添加自定义声明后，需要用户重新登录，或者前端主动调用currentUser.getIdToken(true)强制刷新令牌，才能拿到最新的权限标记。

方案2：Firestore独立存储管理员名单（适合不想使用Cloud Functions的场景） #

如果暂时不想配置服务端环境，可以在Firestore中新建admins集合，以用户uid作为文档id存储管理员账号信息。
实现要点：

• 路由守卫中的判断逻辑调整为：用户登录后，查询admins集合下是否存在当前用户uid对应的文档，存在则判定为管理员放行
• 初始化第一个管理员账号时，可以临时放开admins集合的写权限，手动添加完第一个管理员文档后立刻把规则改回仅管理员可读写
• 缺点：每次进入管理员页面都需要额外发起一次Firestore读请求，相比自定义声明方案多一次网络开销。

方案3：硬编码管理员邮箱（仅适合本地测试/个人极小项目） #

即你最初构思的方案，使用时必须注意：

• 不要把管理员邮箱列表硬编码在前端源码中，可存储在Firebase公开配置文档或环境变量中
• 必须同步配置Firestore/Storage安全规则做后端校验，否则用户可以绕过前端页面直接调用SDK上传数据
• 该方案安全等级极低：如果项目未开启邮箱验证，恶意用户注册和管理员同邮箱的账号即可获取权限，且新增、修改管理员都需要调整配置，绝对不要在正式生产环境使用。

内容的提问来源于stack exchange，提问作者Albert Hsu