订单换个编号就能查看？多租户后台的权限落地与越权验收

企业把经销商订货、客户售后和员工管理接到同一个后台后，容易出现一种隐蔽问题：页面只显示自己的订单，接口却能查到别人的记录。前端隐藏按钮、编号换成随机字符串，都不能代替服务端授权。做深圳网站建设或小程序后台交付时，应把这类检查放进验收范围，尤其是共用数据库的多租户业务。

把身份、租户和资源归属分开处理

登录成功只说明请求者是谁，不代表他能操作任意数据。服务端需要同时判断账号状态、当前租户成员关系、操作权限和目标资源归属。订单属于哪个企业，应从订单记录读取；请求中的租户编号只能作为切换上下文的输入，不能直接当作授权依据。

例如采购员能够查看本企业订单，但不能处理退款；售后人员能够查看工单，却未必有权导出客户电话。开发前整理一张权限表，逐项写明资源、动作、可见范围和敏感字段。别只写“管理员权限”，否则实现和验收都会留下解释空间。

租户上下文从服务端确认

账号切换企业时，后端查询有效成员关系，确认该账号仍属于目标企业，再建立当前租户上下文。成员被停用后，旧登录态也要失去对应访问能力。若权限使用缓存，需要定义失效方式和最长生效延迟，验收时用已登录设备重复请求，不能只测试重新登录。

查询条件要进入数据库访问路径

查订单详情时，使用订单编号与当前租户编号共同查询；更新和删除也应带上相同范围条件。不要先按编号读出记录，再依赖某个页面入口补权限。列表、详情、导出、批量处理、附件下载和异步任务，都需要沿用同一套范围规则。

实现上可在业务服务层集中构造访问范围，再传给数据访问层。对于必须跨租户运行的内部任务，单独提供受限入口，明确调用身份和用途。不要设置一个可由外部请求传入的“跳过租户检查”参数，方便联调留下的开关往往会跟着上线。

关联对象也要检查归属

创建售后单时，即使售后单自身写入了正确租户，也要核对关联订单属于同一租户。修改联系人、绑定收货地址、引用报价单时同样如此。数据库外键只能说明记录存在，不能自动说明两条记录属于同一家企业。相关校验与写入放在合适的事务边界内，避免检查后关系变化造成错误绑定。

三个容易漏掉的访问出口

• 批量接口：逐条核对编号归属，明确遇到无权记录时整批拒绝还是返回逐项结果。不能只检查数组中的第一条。
• 文件与导出：先授权，再生成下载凭据；私有附件不要长期暴露固定公开地址。导出任务执行时和结果下载时均检查访问资格，并设置文件清理期限。
• 缓存与搜索：缓存键纳入租户和必要的权限维度，搜索查询也附带范围过滤。仅在数据库查询上加条件，拦不住缓存命中时的数据串读。

对于客服代查等确有跨企业需求的功能，应设计独立角色和明确的数据范围，记录操作者、目标企业、资源及操作原因。日志避免保存完整令牌、证件和客户联系方式，排错需要的是可追踪的访问关系，不是再复制一份敏感数据。

用两个企业账号做一次完整验收

准备甲、乙两个测试企业，各建普通成员和管理成员，并分别创建订单、工单与附件。只使用测试数据。在甲账号登录状态下，将详情请求的订单编号换成乙的编号，依次尝试查询、修改、取消、导出和下载。还要测试路径参数、查询参数与请求体内的编号，不能只改页面地址。

预期结果应写清楚：无权请求不返回业务字段，不发生写入，也不生成可下载文件。对资源是否存在的提示保持一致，避免通过不同报错探测其他企业数据。批量接口同时混入两家企业的编号，检查返回内容和数据库结果是否符合约定。

角色变更与后台任务单独测

保持旧会话不退出，将账号降权或移出企业，再重放原请求。导出任务则先提交、再撤销权限，检查执行和下载环节。对于深圳小程序开发与深圳APP开发项目，还要覆盖旧版本客户端；权限判断必须由服务端完成，客户端是否更新不应决定数据边界。

交付时留下能复查的材料

交付包保留权限表、测试账号范围、接口验收记录和已知限制，记录中隐藏登录凭据。后续新增接口时，把租户范围、关联对象和敏感字段列为代码评审项。发现越权后，先关闭受影响操作或收紧访问范围，再排查同类接口，并结合访问日志确认影响，不能只修一个页面按钮。

如果企业正在改版官网、整合经销商平台或建设多端共用后台，可以联系讯网科技，结合现有业务梳理权限边界与接口验收清单，让开发和交付都有明确依据。

返回首页 上一篇：企业网站与小程序文件上传安全与提速实操：对象存储直传、大文件切片与格式深度校验指南