多租户API中两种查询方式的安全性与性能对比选型

场景背景 #

我基于ASP.NET + Entity Framework开发API，数据库采用多租户架构存储多家企业数据。用户身份信息来自JWT Token，处理请求时先验证Token并加载用户数据。

示例接口：

• /api/shops/{shopId}/orders：用户传入shopId（一个用户可访问多家店铺），需先验证用户是否有权访问该店铺，再加载过滤后的订单数据。
• /api/shops/{shopId}/orders/{orderId}/items：用户传入shopId和orderId，需依次验证店铺访问权限、该店铺是否存在指定订单、用户是否有权查看订单项，最后加载数据。

现有方案及问题 #

原ServiceFilter方案 #

在控制器层通过ServiceFilter验证店铺/订单访问权限，优势是能在控制器层提前拦截未授权用户（验证不通过则不执行后续业务代码），但存在明显问题：

• 多次重复查询数据库，两次查询使用完全相同的where子句，且都需要传入shopId
• 后续业务查询仍需手动传入店铺信息，代码冗余

内存存储可访问ID方案 #

验证阶段加载用户所有可访问的店铺ID并保存到内存，后续业务查询仅基于这些ID过滤数据。该方案同样能在控制器层拦截用户，但缺点突出：

• 内存中存储的ID数量无上限，用户可访问店铺过多时会占用大量资源
• 仍需执行两次数据库查询（一次加载权限ID，一次查询业务数据）

疑问 #

我应该选择哪种方案？

1. 继续使用原ServiceFilter方案？
2. 改为在控制器方法中仅执行一次数据库查询，不在控制器层提前拦截（但仍会拦截未授权用户）？
3. 采用内存存储ID的方案？

注：ID所在字段已建立索引，后续会基于权限验证得到的ID进一步过滤数据。可能我对用户访问验证的核心逻辑理解不够透彻，希望能理清。

解决方案建议 #

优化原ServiceFilter方案，减少重复查询 #

没必要放弃ServiceFilter的提前拦截优势，重点优化查询逻辑即可：

1. 复用权限验证逻辑：把用户对店铺的权限验证封装成独立服务方法，比如在UserPermissionService中实现bool HasShopAccess(int userId, int shopId)，内部用EF执行一次数据库查询完成验证。ServiceFilter和后续业务查询都调用这个方法，避免重复编写where子句。
2. 传递验证上下文：ServiceFilter验证通过后，将当前合法的shopId存入HttpContext.Items，后续控制器方法或业务层直接从这里获取，无需重复传参或查询。

合并权限验证与业务查询，单次数据库请求 #

如果可以接受不在控制器层提前拦截，可将权限验证逻辑合并到业务查询中，只执行一次数据库请求：

var orders = await _dbContext.Orders
    .Where(o => o.ShopId == shopId 
                && _dbContext.UserShopPermissions.Any(p => p.UserId == currentUserId && p.ShopId == shopId))
    .ToListAsync();

若查询结果为空，直接返回403（未授权）或404（资源不存在）。这种方式减少了数据库查询次数，缺点是要到数据查询阶段才判断权限，但对API用户来说，返回的状态码和体验差异不大。

内存存储ID的优化方向 #

如果坚持用内存存储ID，不要一次性加载所有可访问ID，改用按需加载+缓存的方式：

• 仅针对当前请求的shopId验证权限，将验证结果以UserId_ShopId为key存入缓存（内存缓存或Redis均可），设置合理的过期时间。
• 既避免内存占用过高，又能减少重复的权限验证查询。

权限验证核心逻辑梳理 #

多租户场景下的权限验证需遵循三个核心原则：

1. 最小权限验证：只验证当前请求所需的权限（比如访问某店铺订单时，仅验证该用户对该店铺的权限，无需加载所有可访问店铺）。
2. 提前拦截 vs 合并查询：提前拦截适合权限逻辑复杂、业务查询开销大的场景，能减少无效业务执行；合并查询适合简单权限验证、业务查询开销小的场景，能减少数据库请求次数。
3. 避免代码冗余：将权限验证逻辑封装成独立服务或扩展方法，禁止在控制器和业务层重复编写相同的过滤条件。

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