一家连锁店想让所有门店用同一个订单助手。店员输入订单号，就能回答顾客的配送问题。最容易被忽略的地方是：如果只换一个订单号，就能读到隔壁店的订单，共享助手也共享了不该共享的客户资料。
订单系统已有门店账号和行级访问控制时，应沿用这些边界。如果每家店直接登录原系统已经顺手，没有必要再加一层。新入口的意义，是让不同助手复用查询方法，同时仍由原订单系统决定每次能查什么。
提供方可以接入一个只读订单查询函数，接受订单号和少量筛选条件，返回配送状态及已批准展示的字段。数据库凭证留在提供方环境，EasyNet 连接助手与这个受限操作，不把数据库账号交给店员。
门店范围必须从经过验证的调用身份映射出来，再由查询服务检查订单归属。请求里的店名可以帮助显示，却不能充当授权依据。分页、模糊查询和错误提示也要遵守同样的范围，不能借它们推测其他店的客户是否存在。
真正需要补齐的是门店账号到服务权限的映射，以及人员调店、离职后的变更流程。在同一台电脑上开两个助手窗口、给它们不同名称，并不能证明两家门店已经隔离；需要各自的身份和对应的拒绝规则。
让两名测试店员分别查询自己的合成订单，再互换订单号、修改筛选条件并继续翻页。自己的业务能完成，越界请求被拒绝，而且拒绝信息没有泄露另一店的订单内容，才值得把这个入口交给更多门店。
- 01
甲店员询问订单
自己的身份，不自报店名授权
- 02
订单服务查归属
订单号必须属于甲店
- 03
只返配送字段
其他订单统一拒绝
拒绝读取另一店订单
本地合成访问检查；verified_store 在实际系统中须来自可信身份映射，而不是请求参数。
本地示例 · python
orders = {"O-A": {"store": "A", "status": "shipped"},
"O-B": {"store": "B", "status": "packing"}}
def status_for(verified_store, order_id):
row = orders.get(order_id)
if row is None or row["store"] != verified_store:
raise PermissionError("Order unavailable")
return row["status"]
assert status_for("A", "O-A") == "shipped"
try:
status_for("A", "O-B")
except PermissionError as error:
print(error)预期结果：甲店自身结果为shipped；乙店请求只显示Order unavailable。
接入时的检查项
- 甲店身份能够读取自身合成订单，但读取乙店订单被执行侧拒绝。
- 伪造店名、复用旧链接或扩大分页均不会绕过范围校验。
- 返回值和错误日志不包含另一门店的订单摘要或存在性线索。