使用户通过应用程序连接到数据库的正确方法[关闭]答案

【问题标题】：Correct way to make users connect to database through application [closed]使用户通过应用程序连接到数据库的正确方法[关闭]
【发布时间】：2012-06-19 01:56:47
【问题描述】：

我正在创建一个拥有许多用户的 Web 应用程序。每个用户都有自己的登录名和密码来访问应用程序。应用程序的数据将存储在数据库中。

由于应用程序将有很多用户，我想知道让用户通过我的应用程序连接到数据库的正确方法。

是创建多个数据库用户（帐户）还是简单地使用 master/root 从应用程序连接到数据库更好？

编辑/注意：应用程序用户将无法直接访问数据库。数据库与应用程序在同一台服务器上，不会对外开放。

【问题讨论】：

除了通过您的应用程序之外，用户应该无权访问数据库本身。不这样做就是自取灭亡。
他们将无权访问。数据库位于应用程序的同一台服务器中。
@tecnotron 服务器的物理位置不是回答您问题的重要问题。
添加了一条注释，因为 Hovercraft Full Of Eels 所说的。用户将无法直接访问数据库。
您的应用程序应该使用数据库用户凭据连接到数据库。数据库应该有一个表来保存应用程序用户的凭据，并在您的应用程序中有逻辑来验证存储在数据库中的用户凭据。

标签： java database database-connection

【解决方案1】：

各有利弊。

使用共享服务帐户对数据库进行身份验证具有能够更有效地汇集到数据库的连接的优势。也就是说，可以在用户之间重复使用连接，从而最大限度地减少有时打开新连接的成本高昂的操作，如果每个用户单独进行身份验证，您将不得不这样做。一个明确的问题是，您必须格外小心地验证用户正在运行的任何 SQL，因为该帐户的权限必须能够执行系统中最强大的用户需要能够执行的操作。

为每个用户使用一个帐户可以让您更灵活地为不同的用户分配权限，而无需在您的应用程序中实现您自己的自定义授权方案。此外，它使审核系统更容易一些，因为您在检查数据库连接时知道谁连接了。最后，这种方法可以减少您对 SQL 注入的脆弱性，因为您可以锁定每个用户的帐户（最好在 DB 平台中使用基于角色的安全性），以便只能执行应允许用户执行的操作。

因此，例如，如果他们以某种方式注入了一个 DELETE FROM UsersTable，那么您就会将其锁定，即使注入的命令通过了您的验证逻辑，它也会失败。

如果您的用户知道如何使用数据库工具（尤其是 MS Access）并且可以直接访问数据库服务器，那么还有另一个考虑因素。如果您使用每用户授权模型，您可能会遇到精明的用户绕过您的应用程序并直接针对数据库工作的麻烦。如果您的用户是一群程序员，您可能希望使用共享帐户。

如果您的应用受到大量并发小额交易的用户的大量流量，请使用共享服务帐户访问数据库。

当您同时连接到系统的用户较少，或者您希望提高安全性和/或更好地控制对对象的授权时，请使用帐户/每个用户方案。

【讨论】：

我真的很想学习如何在现场制作中为 1000 个或更多的数据库用户创建和添加不同的角色/权限。
这取决于你的使用场景。我的应用程序有 1000 多个用户，但一次登录的用户很少超过 50 个。并发性比命名用户更重要。
当我阅读您的回答时，我了解到像 amazon.com 这样的网站每个用户登录至少有 1 个用户。
那你没看懂。这与我所说的完全相反。您是否正在编写一个拥有与亚马逊一样多的用户和类似交易类型的网站？

【解决方案2】：

标准解决方案是您的应用程序有一个主登录名/密码来连接数据库。然后创建一个包含如下列的表：

user_id
用户名
密码加密
电子邮件地址
权限

请注意，密码会带来安全问题，您应该使用软件包来处理授权，或者阅读有关该主题的lot。不要将用户密码存储在未经高度加密的数据库中。

【讨论】：

这就是我的想法：连接数据库的主登录名/密码。但是数据库可以有很多用户，有些用户的权限较少。我不知道是创建多个数据库用户更好还是简单地使用主（root）连接到数据库并通过将它们添加为大“用户”表上的行来管理应用程序的其他用户。 .
您的应用程序强制执行权限。使用数据库级权限通常过于繁琐且难以扩展，因此通常不会这样做。
并非每个应用程序都需要扩展到相同的程度。直接身份验证模型可以很好地为 Intranet 应用程序提供服务。
即便如此，拥有直接的数据库权限意味着有一条路径可以在应用程序之外修改数据。让应用程序控制数据库更加健壮，即使在小型设置中也是如此。它可以通过任何一种方式完成：我建议 OP 进行一次登录。