React多用户类型数据访问控制及搜索功能实现咨询

第一原则：所有权限校验、数据过滤逻辑必须在后端完成，前端仅做交互层的展示控制，绝对不能信任前端传递的任何权限相关参数，这是避免数据泄露的核心

1 底层数据结构设计 #

先把表结构理清楚，从存储层就把公开/私有数据的边界划清：

• users用户基础表：存储全量用户的核心基础信息，包含字段：user_id（主键）、email（加唯一索引，作为搜索匹配依据）、role（枚举值：buyer/seller，角色标识）、默认公开的非敏感字段（昵称、头像等，不需要用户授权就能展示的内容）
• buyer_privacy_settings买家隐私配置表：和buyer角色的用户做一对一关联，每个可配置公开的敏感数据对应一个布尔类型开关字段，比如is_purchase_preference_public（购买兴趣偏好是否公开）、is_order_history_public（历史购买记录是否公开），所有开关默认值为false（私密），仅当买家主动在设置页开启后才变为true。

不要把隐私开关直接塞在用户表里，后续如果新增可配置的公开字段，单独拆表的扩展性会好很多。

2 后端核心逻辑实现（权限安全的核心） #

所有接口先过校验，再返回数据，不要给前端留任何越权拿数据的可能：

• 第一层：角色全局拦截
  给所有卖家专属接口（包含买家搜索接口）加中间件，校验请求携带的登录态Token对应的用户角色，非seller角色的请求直接返回403无权限，不进入后续业务逻辑。同理买家专属的隐私设置接口，只对buyer角色开放。
• 第二层：搜索接口数据过滤
  搜索接口入参仅接收email（要搜索的买家邮箱）、分页参数，不要接收任何指定返回字段的参数，逻辑按顺序走：
  1. 校验入参邮箱格式，格式不对直接返回参数错误
  2. 用入参邮箱去users表精确匹配，查不到对应用户、或者匹配到的用户角色不是buyer，统一返回「未查询到对应买家的公开信息」，不要额外透露用户是否存在、角色是什么的细节，避免被恶意枚举邮箱
  3. 查到目标买家后，关联查询对应的buyer_privacy_settings配置，只组装开关为true的公开字段生成返回结构，所有未公开的敏感字段直接不写入返回值，不要返回null或者加「私密」标记，从根源上避免敏感数据流出
     举个正常返回的结构示例：

  {
    "code": 200,
    "data": {
      "nickname": "小李",
      "avatar": "https://xxx/avatar.png",
      "purchase_preference": ["数码3C", "户外装备"]
      // 比如历史购买记录开关未开启，这个字段就不会出现在返回值里
    }
  }
  

• 额外防护：给搜索接口加请求频率限制，避免被恶意遍历爬取所有公开的买家数据。

3 前端React侧实现 #

前端只做交互适配，不承担核心权限校验职责：

• 路由层权限隔离
  封装RequireRole高阶路由组件，路由跳转前校验本地存储的登录态里的用户角色：卖家专属的搜索页路由，仅seller角色可访问，买家访问直接跳转403页面；买家专属的隐私设置页，仅buyer角色可访问。导航菜单也根据当前用户角色动态渲染，买家看不到卖家搜索入口，卖家看不到买家隐私设置入口。
• 搜索功能交互
  1. 搜索栏加前端基础校验，输入内容不符合邮箱格式时直接提示，不用发无效请求
  2. 请求拿到后端返回的数据后直接渲染即可，不需要额外判断字段是否要展示——后端已经做过字段过滤，返回的全是当前卖家有权限看的内容
  3. 异常场景统一处理：接口返回403就提示无操作权限，返回未查询到数据就提示对应文案，不要额外猜测原因
• 买家隐私设置页
  页面加载时拉取当前买家的隐私配置，每个可配置字段对应一个开关组件，用户修改开关时直接调用更新接口，把配置同步到后端的buyer_privacy_settings表即可，配置修改后实时生效。

4 常见避坑点 #

• 不要为了前端搜索方便，把全量买家数据拉到本地做匹配，不仅数据量大了之后页面卡顿，还会直接造成敏感数据泄露
• 不要把权限判断逻辑完全依赖前端本地存储的角色信息，本地存储可以被用户手动修改，所有权限判断必须以后端实时校验的结果为准
• 邮箱搜索必须做精确匹配，不要开模糊匹配，防止通过部分字符遍历爬取全量用户信息
• 不要在接口里返回买家的敏感字段再让前端做隐藏处理，抓包就能直接拿到明文数据，没有任何安全性可言

内容的提问来源于stack exchange，提问作者Adham Khalifa