0

我正在开发具有超级用户概念的应用程序。超级用户是拥有应用程序所有访问权限的用户。所以我最初的想法是在用户表中 id 为 1 的用户将是我的超级用户。但就安全问题而言，这有多安全？有没有其他逻辑可以用来定义超级用户？

我在编码方面做了更多的强调。我还实现了角色和其他访问权限，但我需要做的是像幽灵用户这样的事情。每当他登录时，他就可以访问所有内容，就像他是应用程序之父一样。对于他的访问，我不需要检查任何角色条件或访问条件。可能吗 ？

谢谢。

4

3 回答 3

2

为什么不使用角色？在您的用户表中创建一个列，其中您有“SuperUser”、“Admin”、“ReadOnly”……或者可能只是 0、1、2……并将其与代码中的常量/可枚举匹配。现在您可以轻松更改您的超级用户、创建多个超级用户、授予某人临时超级用户权限、定义其他角色...

于 2013-08-08T08:54:14.937 回答
1

从数据库的角度来看，定义两个或更多用户并授予他们或多或少的权限、使用角色等是有效的。但正如你所说 - 这是关于应用程序的。因此，与数据库安全性并行，您需要从以下方面考虑应用程序安全性：

  • 哪个用户可以获得哪些功能、菜单项、网页等。
  • 如何对其进行配置和参数化等。

我个人更强调应用程序方面，而不是数据库方面。因此，考虑例如 PHP + MySQL，我有 2 个 DB 用户（操作员、管理员），但我的应用程序中的每个（应用程序）用户都有一个数据库表，为他们分配数据库的操作员或管理员登录名并定义数据库的哪些部分他们得到的应用程序。

于 2013-08-08T08:55:21.237 回答
1

作为对其他答案的补充：

不要忘记您可以在数据库级别创建用户和授予/撤销权限。我不会推动您的应用程序用户和数据库用户之间的 1-1 映射，但您可以使用它来实现“角色”并在数据库级别强制执行权限作为额外的保护级别。如果您有一些具有“只读”和/或“匿名”访问权限的用户，这可能会特别有趣。这将防止由于您的应用程序代码中的错误而导致“权限升级”。

超级用户是拥有应用程序所有访问权限的用户。所以我最初的想法是在用户表中 id 为 1 的用户将是我的超级用户。

在 Unix 传统中，超级用户通常是 ID 0。这可能会改进代码（也许），更重要的是让熟悉内核/安全编码的程序员更容易理解。

但是我需要做的是类似ghost user [...] 的访问权限，我不需要检查任何角色条件或访问条件。可能吗 ？

我认为以某种方式“停用”您对某个特定用户的所有安全检查并不是一个好主意。为了提高可维护性并且不通过权限检查使代码混乱，就我自己而言，我会将所有需要检查权限的代码封装在包装器函数或对象中，然后我会在应用程序的其余部分使用该包装器。基于此，如果您按照其他人的建议在应用程序级别实现“角色”，则处理“幽灵用户”应该不是太大的问题。

于 2013-08-08T09:29:09.453 回答