您好，我正在尝试找到存储 ConnectionString 的最佳方法（或好的方法）（我的应用程序将连接到服务器中的数据库，它将持续使用它）以及如何处理管理员帐户。默认情况下，所有登录的应用程序都必须有管理员帐户，对吗？
我认为这样......
那么，你在机器上安装一个应用程序，你将如何配置ConnectionString？我认为如果用户不明白它是什么或者它确实必须是什么，那么要求用户配置这样的东西是错误的？
想象一下有一天，由于任何原因必须更改 ConnectionString，如果登录应用程序的管理员帐户凭据位于服务器的表中，那么如何登录应用程序来更改 ConnectionString？
这是我现在的问题...我不知道如何处理此类事情，是否有任何规则来处理此问题，任何常见的方式，因为我开始更认真地处理此类事情。
注意：我认为这并不重要，但我的应用程序是在 WPF 中开发的。
Hi i am trying to find the best way (or a good one) to store a ConnectionString (my App will connect to a Database in a Server, it will work with it continuosly) and how to handle with the Admin account. For default all the applications with Login must have an Admin account, right?
I think in that way...
So, you install an App on the Machine, how you will configure the ConnectionString? I think that is wrong asking the user to configure such thing if doesn't understand what it is or it really have to be?
And imagine one day that the ConnectionString have to be changed for any reason, if the Admin acoount credentials to Log in the App are in a Table in the Server, how then it will possible to Log in the App to change the ConnectionString?
This is my problem now... I don't know how this type of things is handled, if are there any rules to handle this, any common way because i am starting to work more seriously with this type of things.
Note: I think that is not important but my App is being developed in WPF.
发布评论
评论（4）
使用 MS SQL Server 实现数据库访问安全的一种非常简单的方法是使用“集成安全性 = SSPI”。这样，MS SQL 服务器就可以针对运行数据库访问进程的 Windows 用户实体进行身份验证。使用 MS SQL Windows 身份验证，这一切都可以顺利进行，无需在应用程序中存储任何用户名或密码。
另一种方法是分发一个配置文件，其中包含数据库连接字符串，至少密码已加密。
我们在多台服务器上也有许多 MySQL 数据库，因此 MS SQL SSPI 不包括我们。
对于服务器端软件，我将数据库连接字符串和凭据存储在所有服务器端软件使用的单独 XML 配置文件中。凭证按主题排列，所有数据库信息均已加密。我对所有服务器进程使用一个通用文件，并开发了一个小的加密/数据库配置文件管理 GUI，以便简化管理，并且使用相同代码的所有软件都可以进行通用访问。
对于最终用户软件来说，由于用户维护，使用本地配置文件进行维护太困难。对于“胖客户端”软件，我在 DMZ 中的服务器上维护一个带有加密凭据的单独数据库，拥有该软件的任何人都可以普遍访问该数据库（没有那么多分布式胖客户端软件）。我们的 Web 应用程序软件有一个统一的用户数据库它控制所有应用程序的所有用户/角色的访问，并且所有内容都通过一个系统进行门户管理，因此维护用户数据库要容易得多。
坦率地说，多语言系统越来越难以维护。我会使用我们的主域 LDAP 服务器 (Windows ADS)，但我们公司的政策使所有域成员服务器完全被防火墙阻止，无法访问我们最信任的 VPN 之外的内容，因此在很多情况下都无法访问。
我希望有一天有时间在我们的 DMZ 中设置一个基于 *nix 的 LDAP 服务器，并在那里集中所有凭证信息。
A really easy way to do DB access security with MS SQL Server is use "Integrated Security = SSPI". With that, MS SQL server authenticates against the Windows user entity under which the database accessing process runs. It all happens seemlessly using MS SQL Windows Authentication without the need to store any usernames or passwords within the application.
Another way to do it is to distribute a config file with the database connection string in it, with at least the password encrypted.
We have many MySQL databases on several servers too, so MS SQL SSPI doesn't cover us.
For server side software I store database connection strings and credentials in a separate XML config file that all the server side software uses. The credentials are arranged topically with all database information encrypted. I use a common file for all the server processes and developed a little encryption / DB config file management GUI so management is simplified and access is universal to all the software using the same code.
For end user software it is too difficult to maintain with local config files because of user maintenance. For "fat client" software I maintain a separate database with encrypted credentials on a server in our DMZ that is universally accessible to anyone havinng that software (there is not that much distributed fat client software.) Our web app software has a consolidated user database that controls access for all users/roles for all apps, and everything is portaled through the one system so it is far easier to mantain the user database.
Frankly, the polyglot system is increasingly ugly to maintain. I would use our main domain LDAP server (Windows ADS), but our company policies keep ALL domain member servers completely firewalled off from access outside our most trusted VPN and thus inaccessible in too many circumstances.
I hope someday to have time to setup a *nix based LDAP server in our DMZ and centralize all credential information there.
对于 MS SQL 服务器的连接字符串，您基本上有两个选择：
在连接字符串中集成 Security=True。这假设您配置了数据库，以便批准的用户可以访问它。无论哪种方式，您的连接字符串都应该与应用程序的其余部分捆绑在一起。如果您需要更改它，只需发布新版本即可。 （这甚至适用于最原始的安装版本：“将这堆文件复制到计算机上的目录中”）。
现在，连接字符串几乎可以存储在任何地方，最方便的地方可能是 应用程序设置文件。
如果您想确保您的用户只能使用应用程序提供的功能，而不能直接访问数据库，则必须编写类似 Web 服务的内容，并只能通过它间接连接到数据库。
With connection strings to a MS SQL server you basically have two options:
Integrated Security=Truein your connection string. This assumes you configure your DB, so that the approved users have access to it.Either way, your connection string should be bundled with the rest of the application. If you ever need to change it, you just release a new version. (This works even for the most primitive version of installation: “copy this bunch of files to a directory on your computer”).
Now, the connection string can be stored pretty much anywhere, the most convenient place probably being application settings file.
If you want to be certain that your users will be able to use only the functionality provided by your application and not access the database directly, you'd have to write something like a web service and connect to the database only indirectly through that.
如果您需要将连接字符串存储在配置文件或您选择的其他位置，您可能需要对加密结果进行加密并使用 Base 64 编码回字符串。请在此处查看 Encrypt() 和 Decrypt() 实现。
If you need to store the connection string in a configuration file or somewhere else of your choosing, you might want to encrypt and base 64 encode the encrypted results back into a string. Check here for an Encrypt() and Decrypt() implementation.
在应用程序安装过程中可以操作文件（例如 .config 文件）。因此，可以向用户/管理员（在设置过程中）询问服务器的名称（甚至询问用户名和密码，前提是您对这些进行加密，但我宁愿使用集成安全性）。
要更新连接字符串，只需创建一个新的安装程序。
替代方案：将连接字符串存储在活动目录或其他知名存储中，因此您所需要做的就是更改一个位置的值。
It is possible to manipulate files (such as the .config file) during the install of the application. So it is acceptable to ask the user/admin (during setup) for the name of the server (and even for a user name and password provided you encrypt these but I'd rather use integrated security).
For updates of the connection string just make a new installer.
Alternative: store the connection string in active directory or in an other well-known store so all you need to do is change the value in one place.