java我的用户应该直接连接到数据库吗？如何将用户连接到数据库；
首先我必须提到，我对数据库相当陌生
目前我设置了一个MySQL服务器，我不确定如何将我的用户连接到数据库； 我希望他们能够使用我的软件应用程序发送某些预定义的查询（SELECT/ALTER）
目前我的做法是：我在第一个表单中要求输入用户名/密码。然后，我使用默认用户名：“javaApp”/password：“javaApp”连接到数据库，然后检查登录表单中给出的数据是否对应于UserTable中的用户
有人能提供关于如何更有效/更专业/更安全地完成这项工作的见解吗
也许是网络服务什么的？我真的没有任何想法
专业软件开发人员如何解决这个问题
提前谢谢
# 1 楼答案
我认为，这在很大程度上取决于您在安全性、易用性等方面想要实现什么。各有利弊。通常这是一种权衡
为所有用户连接一个数据库帐户
优势：
灵活性：您不受DBMS提供的访问限制方法的约束
例如，您可以在应用程序的权限管理中包含可能不适用于DBMS权限管理的业务规则
如果不使用DBMS权限管理的任何特性，那么更改DBMS也可能更容易。如果应用程序保持不变，则访问控制保持不变
您可以根据需要在应用程序中设计用户管理，使其尽可能简单方便。如果使用DBMS管理用户，则仅限于它为该作业提供的工具
如果DBMS在权限管理方面存在缺陷，并且相应的公司或社区没有提供补丁，那么您就无能为力。如果程序中出现这种情况，您可以自己修复
使用您喜欢并已掌握的工具：您可能更容易在应用程序中正确地执行此操作，因为您对它和相应的编程语言都很熟悉。也许你还不太了解数据库管理系统
这可能会影响解决方案的质量
缺点：
单点故障：从DBMS的角度来看，您的所有用户都是同一个用户
也就是说，如果这个账户因为任何原因落入坏人之手，那么一切都将失去。当然你可以（也应该！）在DBMS方面尽可能多地限制这样一个DBMS帐户。但是任何有权访问此帐户的人都可以执行应用程序中最高权限允许的任何操作
还记录了谁做了在这种情况下可以规避的事情。由于入侵者拥有应用程序拥有的所有权利，而DBMS无法区分可能是谁，因此他们可以模仿所有他们喜欢的用户。甚至可能操纵（数据库中的）日志。找到袭击的痕迹可能更难
应用程序必须知道单个数据库帐户的密码（或任何凭证），以便在登录时将其提供给DBMS。显然，尤其是你不能将这些知识“外包”给用户的大脑。如果他们知道这一点，他们可以通过简单地使用通用客户机（例如MySQL Workbench）做应用程序不允许做的事情，轻松绕过您的应用程序。而来自内部的攻击也并不罕见。例如，一些用户操纵其他人的工作，以便在管理层进行促销之前看起来更好。或者有人觉得被公司出卖了，想要报复。你说吧。（如果不是商业项目，也可以用社区代替公司。）
它必须物理地存储在应用程序可以访问它的地方。尽管可能有一些措施可以很好、安全地处理，但它仍然比仅仅在用户头脑中更容易暴露
如果您必须更改单个帐户的密码，则可能必须以某种方式将其部署到应用程序的所有安装中。这可能不是一个（大）问题，但这取决于应用程序的部署方式
未经充分测试：如果您使用其中一个著名的DBMS，您可以确定其他许多人都在使用它。很多人已经测试过了。有些人甚至可能已经明确审计了它
这些数据库管理系统中有一个缺陷的概率（允许帐户突破其限制，但不是0）可能远低于您的应用程序中某些隐藏的缺陷，可能传播范围较小，受支持程度较低
（抗辩）别把那当作侮辱。我不怀疑你的技能或任何东西。但我只是假设你不是重量级的合作伙伴，比如Oracle，你可以投入几十亿美元的资源，或者（然而）在你背后有一个大型开源社区，有很多自愿的志愿者。）
对于每个用户，一个不同的数据库帐户
优势：
减少影响：您不会遇到单一故障点（即针对所有用户的单一DBMS帐户）带来的所有问题
当然，如果攻击者获得超级用户帐户，那么无论哪种方式，您都完成了。但是，即使有人可以窃取你的一个普通用户的帐户数据，他们也不能像这个用户那样做得更多。当然，为了减少此类事件可能造成的影响，您必须尽可能降低此处的权限
由于DBMS清楚地知道它在与谁打交道，因此可以安全地记录用户操作，避免可能的操作。你可以重建做了什么以及是谁做的。确保日志不会对你撒谎
您可以将登录凭据“外包”给用户。无需将其物理存储在应用程序可访问的位置。它暴露的更少。（前提是用户不把它写在键盘旁边的帖子上或是其他有趣的东西上。但是，那是另一回事了……）如果一个用户的密码需要更改，它根本不会影响其他用户或程序的安装
测试良好，支持良好：如上所述，如果您使用一个著名的DBMS，您可以肯定其他很多人都在使用它。它经过了很好的测试，甚至可能经过了明确的审核
因此，DBMS中存在漏洞的概率可能比您的应用程序低很多。。而且，支持社区或公司可能会随时提供针对此类错误的修复
这对你的项目来说可能并不重要。我无法判断这个比例。但我不想让它被忽视，某些DBMS提供了在组织的复杂it环境中集成的方法。这也是关于用户管理的。例如，在SQL Server Active Directory中，可以使用用户。这可能有助于全面简化、集中和/或标准化组织内的用户管理，从而降低出错的可能性。用户也可以方便地进行单一登录
缺点：
更少的自由度：使用DBMS进行用户和权限管理，您必须遵守其规则
DBMS可能不会提供您需要的特定方法或特定级别的访问限制。您可能会发现，要使DBMS的权限管理按照您的某些业务规则运行是不可能的。在这种情况下，你不能做太多
如果您想更改DBMS，您可能会发现，您在旧DBMS的用户管理中使用了许多新DBMS无法实现的特性。你可能得从头开始
您必须得到生产DBMS的公司或社区的支持。如果权限管理中有一个bug，对您造成了威胁，而且公司或社区没有提供补丁，您对此无能为力
可能需要学习：特别是当您刚接触DBMS世界时，您需要学习了解DBMS通常可以提供的访问控制方式，以及特定DBMS如何提供访问控制，或者它还可以提供什么
当然，这不是一件轻而易举的事，一开始你可能会犯一些错误
结论
每种方法都有各自的优点和缺点
如果安全性要求不高，那么采用“单一DBMS用户为所有用户”的路线可能是正确的选择。更大的灵活性可能会超过它
另一方面，多个DBMS帐户提供的安全级别要高得多。如果这是一个问题，特别是当我们谈论敏感数据时，这可能是更好的选择，甚至是唯一合理的选择
甚至混合解决方案也可能是正确的选择。在DBMS的访问限制中总是有一个后退，最重要的是，在应用程序中放置您自己的
要决定哪种方法最适合一个项目，必须考虑到它的需要，并且必须权衡利弊。我想没有一个最好的办法
# 2 楼答案
我不会直接公开数据库。我将在用户和数据库之间使用一个层，以便您可以控制他们如何查询数据库以及检索什么
不要在代码中定义数据库连接。相反，使用JNDI资源（特别是如果您运行在应用服务器上，例如为您管理JNDI资源的Tomcat）。这将使代码与连接信息分离。此外，您还可以使用JNDI连接池之类的功能来提高应用程序的性能（还可以处理连接关闭之类的功能）。并发将由连接池处理。见本Oracle article on JNDI resources和this one specific to Tomcat
使用服务帐户，即用于向数据库验证应用程序的帐户。该帐户和访问您的应用程序的个人的用户帐户无关。限制服务帐户可以执行的操作。如果您只想通过应用程序读取数据，那么将服务帐户限制在该范围内（至少在开始时）
您可以使用ORM，例如Java中的Hibernate，它将为您提供数据库的抽象视图。如果你只有一张桌子的话，这对你来说可能太多了。在这种情况下，使用一种叫做PreparedStatement的语句
您希望厌倦让用户定义自己的SQL语句。这会让你面临很多SQL攻击（寻找SQL注入）
永远不要将用户凭据存储在数据库的clear中。散列值
最后，看看这些awesome best practices