【问题标题】:Should I validate access permissions each request?我应该验证每个请求的访问权限吗?
【发布时间】:2013-06-14 18:50:09
【问题描述】:

我一直想知道,是否最好在每个请求中检查数据库的帐户访问权限,还是在会话状态下缓存(例如 ACL)。

我目前的情况并不是特别关键,但我觉得必须注销并重新登录以刷新缓存的凭据会很烦人。我还考虑过使用带有 TTL 的临时数据存储。似乎它可能是两者中最好的。

【问题讨论】:

  • 为权限表提供一个关于用户 ID 的聚集索引并获取用户的权限列表应该很少或没有服务器负载,使缓存毫无意义。
  • 嗯...我没有集中的权限表——该信息在多个 m:n 表中。你会推荐集中化吗?
  • 针对特定请求需要检查多少个表?每个表有多少行?如果您必须检查多个表,那么集中化将是明智之举,因为您将 N 次聚集索引扫描(在用户 ID 上)转换为仅返回更多行的一次。
  • 现在只有两三张表,每张有几百行,但我希望它会增长不少,并希望尽可能避免不必要的数据库查询

标签: security validation web-applications user-permissions


【解决方案1】:

安全方面,最好每次都检查数据库的权限。安全漏洞在于,如果用户的权限在创建会话后减少,他们可能仍会获得比应有的更高级别的访问权限。

如果您在开发周期中处于足够早的阶段,您可以在不执行完整查询的情况下采取一些措施来确保安全。如果您有role-based access control (RBAC),您可以存储一个包含用户角色的快速查找表。如果用户的角色在会话期间发生更改,则在查找表中将权限标记为“脏”,从而导致数据库查询新角色。只要用户的角色保持不变,就不需要查询数据库。那么,查找表基本上只是一个标志,如果用户的角色发生变化,您可以在后端设置它。如果粒度不太细,即使对单独的访问控制也可以使用相同的技术。如果是,它开始在您的服务器上变得臃肿。我们在工作中使用这种技术来加快交易速度。

如果您处于开发周期的后期,或者您更看重简单而不是性能(简单通常更安全),那么我会每次都查询数据库,除非数据库的负载过重。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-11-19
    • 2017-06-13
    • 2013-06-18
    • 1970-01-01
    • 1970-01-01
    • 2015-07-30
    • 2013-03-28
    • 1970-01-01
    相关资源
    最近更新 更多