在 Web 应用程序中的何处存储数据库凭据？
我想知道您使用什么技术来存储应用程序的数据库凭据。 我特别关心 java webapps，但我认为没有必要将问题限制于此。
需要考虑的事项：
您使用属性文件、xml 配置文件或其他文件吗？
它是捆绑到您的应用程序中（即在 jar 文件中）还是单独存储在文件系统的某个位置？
密码是否加密？ 如果是这样，您使用什么加密方案？
I'm wondering what techniques you use to store the database credentials for your application. I'm specifically concerned with java webapps, but I don't think there's any need to limit the questions to that.
things to consider:
Do you use property files,xml configs, other?
Is it bundled into your application(ie in a jar file) or stored seperately on the file system somewhere?
Is the password encrypted? If so, what encryption scheme do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
由于您将问题留给平台，我将添加 .NET 应用程序的数据库凭据存储在 web.config 文件中。 从版本 2.0 及更高版本开始，有一个特定的 ConnectionStrings 部分，可以更轻松地以编程方式访问连接字符串。
除了默认情况下 IIS 自动阻止对 web.config 文件的直接请求之外，您还可以使用 IIS 命令加密 web.config 文件的 ConnectionString 部分。 这种加密是特定于机器的，这增加了它的优势，并且当您访问连接字符串时，.NET 运行时也会动态解密它，因此不需要在应用程序中进行额外的编码即可使用它。
Since you're leaving the question open to platform, I'll add that database credentials for .NET apps are stored in the web.config file. From version 2.0 and above, there is a specific ConnectionStrings section that allows for easier programmatic access to the connection string.
In addition to having IIS automatically block direct requests to the web.config file by default, you can also use an IIS command to encrypt the ConnectionString section of the web.config file. This encryption is machine specific, adding to its strengths, and the .NET runtime will also decrypt the connection string on the fly when you access it, so there is no need for additional coding in your application to work with it.
对于 Java，数据库连接池应该由容器传递到 Web 应用程序中。 这是在 WEB-INF/web.xml 中作为资源的标准声明。 这同样适用于邮件会话和其他外部资源，这些资源可能因安装而异。 查找 JNDI 以获取更多信息）
这样做的好处是应用程序不关心如何实际连接到外部的任何东西。 它不会看到任何密码，因为容器本身将使用它们。
在 tomcat 中，这是从 conf/Catalina/localhost/ 、conf/server.xml 中的上下文文件（例如）配置的，或者 - 最好仅针对开发环境，从 webapps META-INF/context.xml 进行配置。 其他环境有自己的配置位置或应用程序。
密码的加密实际上取决于容器。 Tomcat 以明文形式存储它们，但应用程序本身看不到它。 我不知道其他环境下的机制。
With Java, database connection pools should be passed into webapps by the container. This is in the standard declarable in WEB-INF/web.xml as resources. The same applies to mail sessions and other external resources that may vary from installation to installation. Look up JNDI for more information on this)
The nice part with this is that the application doesn't care about how to actually connect to anything outside. It will not see any passwords, because the container itself will use them.
In tomcat this is configured either from context files (e.g.) in conf/Catalina/localhost/ , conf/server.xml or - preferably only for dev environments, from the webapps META-INF/context.xml. Other environments have their own configuration location or application.
The encryption of passwords actually depends on the container. Tomcat stores them in plaintext, but the application itself won't see it. I don't know about the mechanics in other environments.
在 Microsoft 堆栈上，一切都非常美好。
您在 Active Directory 中创建一个几乎没有任何权限的网络用户帐户。 您将 IIS 配置为以该用户身份运行您的 Web 应用程序。 您授予该用户对磁盘上的 Web 文件夹和文件的读取权限。 您将 SQL Server 配置为授予该用户对所需表的读/写权限。 在连接字符串中，您指示数据库客户端以 Web 应用程序当前运行的用户帐户进行连接。
尽管在多个地方都可见，但只有一个实际用户帐户。 该用户帐户的权限极其有限。 即使加密，也不会在任何地方存储密码。 无需在代码中进行任何配置即可使其工作（这一切都在设置权限中）。
On the Microsoft stack, things can be very nice.
You create a network user account in Active Directory with almost no permissions. You configure IIS to run your webapp as that user. You grant that user read access to the web folders and files on the disk. You configure SQL Server to grant that user read/write permissions on the tables you want. And in the connection string, you instruct the db client to connect as the user account which the webapp is currently being run as.
There is only one actual user account, although it is visible in multiple places. This user account has extremely limited permissions. There is no storing passwords anywhere, even if encrypted. There is no configuration that has to be done in code for this to work (it's all in setting up the permissions).
取决于应用程序服务器。
我通常使用 JNDI 查找数据源，因此凭据存储在处理连接池的应用程序服务器上。 通过这种方式，无需在配置中添加 JNDI 名称以外的任何内容。
是的，密码在 WebLogic 上已加密。
在 Tomcat 上，事情可能会很危险。 连接信息位于 META-INF/context.xml 中，这意味着密码的纯文本。 我这样做只是为了开发，而不是在生产中。
Depends on the app server.
I usually use JNDI lookups for the data source, so credentials are stored on the app server that handles the connection pool. No need to put anything other than the JNDI name in configuration that way.
Yes, the password is encrypted on WebLogic.
On Tomcat things can be dicey. Connection info is in META-INF/context.xml, which means plain text for the password. I only do that for development, never in production.
在 Django 中，凭据位于您的
settings.py配置文件中。 由于它通常不会保存在您的/var/www/目录树中，因此非常安全。此外，单个 Django 应用程序可以用于（并重复使用）同一主机上的许多网站或 Web 服务器，每个网站或 Web 服务器都有自己不同的设置。 因此，settings.py 配置未与应用程序捆绑在一起，而是应用程序单个部署的一部分。
In Django, the credentials are in your
settings.pyconfiguration file. Since this is not generally kept in your/var/www/directory tree, it's very safe.Also, a single Django application may be used (and reused) for many web sites or web servers on the same host, each with it's own distinct settings. So the
settings.pyconfiguration is not bundled with the app, but is part of a single deployment of the app.对于 asp.net：
我将全局参数（例如连接字符串和存储库路径）存储在注册表中，然后将注册表项的引用存储在 web.config 中。
主要原因是我经常发现我必须编写一个独立的可执行文件来运行后台任务和其他需要访问相同参数的自动化功能。 因此，将真正全球化的一切都放在一个易于访问的地方可以让生活变得更轻松。
For asp.net:
I store global parameters such as the connection string and repository paths in the Registry and then a reference to the registry entry in the web.config.
The main reason being that I often find I have to write a stand alone executable to run background tasks and other automated features that require access to the same parameters. Therefore keeping everything that is truly global in one easily accessible place makes for an easier life.
如前所述，没有指定平台，并使用之前答案中的一些想法：
我正在考虑容器化应用程序。 您可以将数据库的密码存储在容器中的文件中。 应用程序的第一步是建立数据库连接，甚至在侦听 Web 请求之前也是如此。 数据库连接成功后，带有凭据的文件将被删除，并且包含这些凭据的变量也将被删除。 因此，当您开始处理请求时，唯一剩下的就是从现在开始使用的开放数据库句柄。 如果由于任何原因数据库连接丢失，您只需退出并等待重新启动容器，凭据文件就会再次出现。
As stated before, no platform specified, and using some ideas from earlier answers:
I am considering a containerised application. You could store the password for the database in a file in the container. The first step of your application would be to establish the database connection, even before listening on web requests. With a successful db connection the file with the credentials is deleted and the variables containing the these, are removed. So when you start serving requests, the only thing that remains, is an open database handle to use from this moment on. If for any reason the database connection is lost, you simply quit and wait to restart the container, the credentials file will be there again.
以下哪些位置适合保存 Web 应用程序的数据库凭据？
在源代码中的单独文件中
在 Web 服务器主机上的单独文件中
在你的数据库中
没有任何。 数据库凭证永远不应该被存储
Which of these are good places to keep your web app’s database credentials?
In a separate file in your source code
In a separate file on your web server host
In your database
None. The database credentials should never be stored