如何避免“One Big Application User”模式？
我正在用Java编写一个小型Web应用程序，我的想法是将数据库用户用作应用程序用户。 如果您从未听说过，Oracle在本文档中建议采用这种方法。 基本上，用户将使用他们的数据库凭证进行身份验证，并且我会将这些凭据转发给实际的验证过程的dbms。
我的问题是，每次我需要为用户打开连接时，我都需要他们的凭据。 我提出了两个想法，但对我来说这两个想法都不是完全合适的：
有没有其他选择我没有想到？ 如果没有，这些似乎是最好的？
我想说，在应用程序中，可以将应用程序用户映射到数据库用户的情况非常罕见。 将其看作更多的用户 - >角色映射。
要这样说，在你的应用程序中，这是一种留言板，你将拥有一个带有表格POSTS，USERS和SETTINGS的数据库。
再次，您将有三种类型的用户，用户，版主和管理员。 您可能会在所有这些用户之间出现某种控制器级别的分离，这意味着用户，版主和管理员需要使用不同的代码。 该文章指出，您不应为一切目的使用一个超级用户数据库帐户。
考虑这个解决方案。 对于用户组，您应该有一个USER数据库用户，该用户只对表POSTS具有WRITE权限。 版主的控制器应该使用单独的数据库用户连接到数据库，该用户有权读取和写入POSTS，但没有任何超过USERS和SETTINGS的权限。 正如你可能怀疑管理员面板应该拥有自己的用户/角色几乎所有的权限。
您也可以放置另一个用户，当您要验证留言板上的注册用户时，只有USERS表的读取权限。
这是一个相当简单的方法，但这样你可以防止数据库从应用程序逻辑中可能存在的错误中泄漏出来，这些错误可能会泄露不想破坏数据库的请求，或者至少可以控制可能的损害。
总结一下，这是一个非常简单的机制（对于你正在构建的系统来说，我猜测它足够简单）。 这样你就不会真的得到任何供应商锁定（如果你选择有一天去MySQL或者SQLite或者与Oracle不一样的东西），并且你可以从控制器模型解耦中获得更多的利益。
正如一些评论人员指出的那样，您甚至有一天可能会引入更复杂的身份验证方法，因此使用数据库集成机制会成为迁移问题。
分级数据库安全性文件有什么好处呢！
“一个大型应用程序用户”的支持者在开发人员，管理人员和管理人员中有很多不好的公司，他们不想去了解他们正在使用的DBMS。 所有这些DBMS都具有丰富的审计和安全功能，如果您利用数据库级用户，这些功能可能无法估量。 相反，OBAU把它扔掉了。
所以我会使用命名的，标识的数据库用户。 但是，我宁愿使用LDAP身份验证而不是数据库来保护每个这样的数据库用户。 （您可以使用Oracle LDAP服务器，但这不重要）。我会将LDAP会话凭据存储在Web会话中。 请注意，我们希望凭证在几天或几小时后过期！
Oracle还实施了“轻量级”会话（11gR2？），您可以保持打开状态而不是集中它们。 我从来没有在连接池中完全销售 - 为什么数据库连接是管理员永远不会沿着“摩尔定律”系列增长的唯一资源？
通过将同义词和视图收集到一个模式中，您可以继续集中您的访问权限。 您还可以将表格存储在那里，并使用VPD / DBMS_RLS进行保护，除了我个人的审美观点外，它在任何情况下对我来说都是防弹的。
连接完成后，进行会话ALTER SESSION SET CURRENT_SCHEMA = CENTRALIZED_OWNER，这样程序员就不必在CENTRALIZED_OWNER.tablename中为每个数据库对象加上前缀。
尝试使用AUTHID CURRENT_USER（或其他DBMSes的等价物）编写您的过程（在Oracle中）以保持实际最终用户下的权限管理。
当您的开发人员尖叫访问表时，GRANT会代理访问它们以获取该安装中的表所有者模式。 这是一个神话般的功能。
祝你有美好的一天！
安德鲁沃尔夫
链接地址: http://www.djcxy.com/p/22239.html上一篇: How to avoid the "One Big Application User" model?
下一篇: How to pass authentication details in a HTTP DELETE request?