Is it possible to use connection strings in a Console app's app.config file in a single machine config file instead? So all console apps on the server can use the same file?
You could, but that would mean that any .NET application could gain access to your database.
I would advise against it, for several reaons:
A possible security hole.
Most developers would look for this information in app.config not machine.config.
You may end up sharing connection strings that only one or two applications need with all applications.
You can't limit what applications will be able to use the connection strings.
You will not be able to simply move the application to another machine, with the app.config file and have everything just work (you will also need to import the connection string information to the new machine.config).
You really should keep the configuration with the application that uses it.
Related
I have a winforms application that connects to a database with a connection string and a generic user
"Database=DBADAS;Server=TMT123\\SQLEXPRESS;User ID=user; Password=*****;
After connecting into the database with a login dialog, we check if the user and password are existent in the user table from the database.
My question is now if this is a good practice? because basically in the connection string there is every information needed to crack the server.
There are a few ways to go about this safely. Since it's a Winforms app and not a web application, most of your security risks involve someone already in your network peeking at the connection string. This adds a layer of security in and of itself.
1. Hardcoded
You can hardcode the connection string that fetches the users into a DLL and make your application depend on that DLL. I only suggest this because it sounds like the "generic user" password is permanent; otherwise, you'd have to recompile code every time you changed the password, then deploy again. This is very secure, however, as the value isn't stored in plain text.
2. App.Config
You can stick it in a configuration file. Within a secured network, this is probably the most versatile option, as you can store multiple strings and easily update them without updating the full application. This goes well alongside settings like a "DebugMode" setting, etc. Using App.Config or another XML file is ideal, but you can roll a quick and dirty .txt file, too.
3. Database
Probably the most secure way of all, as you can encrypt your database and code your programs to fetch their connection strings and login information from that database by using an unrelated login. This allows greater control over what can be reached by the application when a user has not yet logged in. It also prevents the software from operating outside of the network, which may be desirable.
4. Internal API
Having a separate application serve this data divorces user capability from your concerns, as the API and your app can exchange verification keys to see if your app even has permission to try to connect. This is my personal favorite, but obviously the most work to set up.
5. Registry Entry
Depending on how you have this installed, it may work well to embed the tokens you need in the Registry. This guarantees the app requires admin permissions to install, and allows you to use Windows security to restrict access to the hive.
Again, since it's an internal non-web app, I wouldn't worry too much about the plain text of the connectionstring; if someone has gotten this far into your network, chances are you have much bigger problems already. I wouldn't leave it floating as a plain text file in a local directory, but any degree of security above that is probably acceptable for your purposes.
Encrypting Web.Config
Open Command Prompt with Administrator privileges
At the CommandPrompt, enter:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
In case your web Config is located in "D:\Articles\EncryptWebConfig" directory path, then enter the following to encrypt the ConnectionString:
ASPNET_REGIIS -pef "connectionStrings" "D:\Articles\EncryptWebConfig"
Use Aspnet_regiis.exe tool with the –pef option and specify the application path as shown above.
Note: The parameter "connectionStrings" is case sensitive.
For Winforms: You need to rename your app.config to web.config encrypt it by using steps 1 to 3 and again rename it to app.config.
Reference: https://www.codeproject.com/Tips/795135/Encrypt-ConnectionString-in-Web-Config
I have a question regarding a WinForm application and ClickOnce Deployment.
Currently, I use the Visual Studio Installer for creating my installer. One of the things that I do is I have created a custom installer class that I use for entering in certain information (servername, database name, username, password, port number - which is needing for my connection string to the DB). This information gets written to my app config file. However, this makes updates a pain, so I am looking into ClickOnce Deployment instead.
For those of you that do something similar, what's the best way to go about handling this? Is it possible for me to include a config file with my ClickOnce Deployment project that will just copy the settings from that file during the installation? Or, what is the recommend best practice for handling this?
Thanks everyone.
My ClickOnce application also accesses a database. I created a separate program that asks for the database information and encrypts it into a .DAT file. The .DAT file is added to the main program. You must change a setting on the file to Content so that it is included in deployment. The main program opens the .DAT file and decrypts it for the information. This way no one that uses the program knows any of the database information.
I am working on a new web application using Scala with Lift. I want to make it reusable so others might install it on their own servers for their own needs. I come out of a PHP background where it is common practice to create an install form asking for database connection details. This information is stored in a configuration file and used by the rest of the PHP application for connecting to the database. It is extremely convenient for the user because everything is contained within the directory storing the PHP files. They are free to define everything else. My Java/Scala background has all been enterprise work where an application was only intended to run on the database we setup for it. It was not meant to be installed on others' web servers or with different databases.
So my question is how is this typically done for the Java/Scala world? If there are open source applications implementing the mainstream solution, feel free to point me to those too.
I use this to set up the database:
val vendor =
new StandardDBVendor(
Props.get("db.driver") openOr "org.h2.Driver",
Props.get("db.url") openOr "jdbc:h2:mem:db;AUTO_SERVER=TRUE",
Props.get("db.user"),
Props.get("db.password"))
LiftRules.unloadHooks.append(vendor.closeAllConnections_! _)
DB.defineConnectionManager(DefaultConnectionIdentifier, vendor)
The 'Props' referred to will then be (by default) in the file default.props in the props directory in resources.
Updated: This is what I do on servers in production. With 'Props.whereToLook' you provide a function that retrieves an input stream of the configuration. This can be a file as in the example below or you could for example fetch it over network socket.
You will probably let the application to fail with an error dialog.
val localFile = () => {
val file = new File("/opt/jb/myapp/etc/myapp.props")
if (file.exists) Full(new FileInputStream(file)) else Empty
}
Props.whereToLook = () => (("local", localFile) :: Nil)
I am not sure if I am missing your points.
By default, Lift use Scala source file(Boot.scala) to configure all the settings, because Lift doesn't wanna introduce other language into the framework, however you can override some of the configurations using a .properties file.
In Java/Scala world, we use .properties file. It's just a plain text file used for configuration or localization etc,just like text configuration files in PHP.
Lift Framework has it's default support for the external database configuration files, you check out the code in Boot.scala, that's if a .properties file existed, the database will initialized using the connection configuration, if it doesn't, it will use the source file configuration.
So I have a local WPF web browser application and I need it to write to a text file. However I always get the an exception of type System.Reflection.TargetInvocationException. I don't get any more information but I'm pretty sure it is because it is being run from a web browser (security etc.).
The code I am using works in a regular windows form application etc. it is the usual:
StreamWriter sw;
sw = File.CreateText("c:\\myTextFile.txt");
sw.WriteLine("First line");
sw.Close();
So, is there a workaround for this?
Many thanks,
Thomas
You could try running in Full Trust mode.
WPF in a browser is going to default to partial trust. You can change that in the Security tab in Project Properties (subject, of course, to it being installed by a trusted user).
The issue is not WPF security problems. The issue is an operating system security feature in play: you can't write to the root of the C: drive without admin privs. Not only would your app need to be in WPF Full Trust mode, but you'd need to grant your app administrative priveledges on Vista and Windows 7 and beyond.
All that said, you should be able to write to files in non-protected paths. For example, you could write to a temporary file as returned by Path.GetTempFilePath(). However, it's likely your WPF browser app will still have to be running in full trust to write to disk at all.
See this page, describing Partial Trust security considerations. If you need to store the file for your own application's use, consider using Isolated Storage. If you want to allow the user to save a file to disk, you can use SaveFileDialog.OpenFile to allow the user to choose a path and confirm saving the file.
I'm working on a website in JSP (in GWT really, but on the server side, it's really just JSP), and I need to configure my database.
I know HOW to code in the database connection etc, but i'm wondering how/where the database config should be saved.
To clarify my doubt, let me give an example; in PHP, a website usualy has a config.php, where the user configures the database, user, etc (or an install.php generates it).
However, since JSP is bytecode, I can't code this info into my site and have the user modify it, nor can I modify it analogously to an install.php.
How should I handle this? what's the best/most common practice ? I've found NO examples of this. Mainly, where should the config file be stored?
There are several possibilities to do this, what I've seen done include:
Having database credentials in a special file, usually db.properties or some simple XML file that contain the required information (driver, url, username, password, any ORM parameters if needed). The properties file would be placed under WEB-INF or WEB-INF/classes; the downside of this approach is that the user would have to modify the file inside the WAR before deploying it to the application server.
Acquire the database connection via JNDI and expect it to be provided by the application server. This seems to be the most common way of doing this; on the upside, your WAR doesn't have to be changed, however, the downside is that configuring a JNDI data source is different for every application server and may be confusing if your system administrators are not experienced with Java technology.