我应该将Postgres的角色系统用于Web应用程序的用户管理吗?

nii*_*nii 11 php postgresql web-applications

Postgres已经拥有功能齐全的用户管理系统.为什么我要复制这个功能并在其上再使用另一个?我认为这是管理用户和群组的合适场所,因为它允许细粒度控制.我错了吗?是否有一些PHP库已经做到了?
我应该补充说,有问题的应用程序不是公共网站,而是在专用网络中工作的企业应用程序.

Cra*_*ger 7

我强烈建议应用程序设计人员使用PostgreSQL的用户和角色系统...但是出于多种原因,将应用程序用户与数据库用户进行1:1映射通常是不实际的。

  • PostgreSQL角色在所有数据库之间共享(尽管除了一个数据库外,不必授予它们角色的其他权限)

  • 您不能从普通应用程序表到PostgreSQL用户表有外键引用

  • 没有任何功能或其他界面可以通过密码对用户进行身份验证。您必须建立新的连接才能通过密码进行身份验证。这会中断连接池。

相反,我建议您在数据库中使用几个角色

  • 数据库所有者角色。该用户/角色拥有数据库及其中的表。更改数据库结构的脚本(“迁移”等)以该用户身份运行。

  • 一个webapp角色。这是应用程序在建立池连接时所连接的角色。这GRANT仅是每天运行时应用所需的访问权限。它不能更改表结构,删除表等。如果表应该是仅追加表,则您不授予UPDATE该角色权限。

  • (可能)脚本等维护角色,这些角色只能访问其任务所需的内容。

您可以使用普通表管理应用程序用户。

有时您还需要特定用户类别的其他数据库角色。如果您要处理具有不同特权级别,部门等的应用程序,则这会很方便。Web应用程序可以SET ROLE切换角色,因此,如果“ joe”已连接并且您知道“ joe”在帐户中,则在设置“角色”帐户之前运行乔的查询。这是更高级的,大多数人不需要它。

我认为直接使用PostgreSQL用户管理是有意义的,主要是当该应用程序具有非常复杂的访问要求并且不需要大量不同用户(数千而不是数百万)时。对于webapp,我会坚持使用普通的数据库表,只是将“ db admin”角色与webapp连接池角色分开。

  • @nii 说 PHP 意味着没有连接池问题是没有意义的。您可以使用 PHP 中的池,或者像 PgBouncer 这样的代理池,这样做很常见。但是,对于数百个并发用户,您可能不需要这样做。如果您正在考虑使用 RLS 等,那么它可能值得一试。拥有数据库内用户的好处是你可以“授予”每个用户他们需要的特定角色,反过来“授予”这些角色他们需要的特定权限。 (2认同)