I need to generate machineKey in my web application installer and put it into the application's web.config. How can I do this?
We need to split the answer in two:
Generate the Machine Key: You will need to implement a custom action to generate the Machine Key (There are many tutorials about creating custom actions so I won't cover that here, review the links below). The important part is the code to generate the Key, review these links: C#, Powershell. You can store the result on an installer property, you may need to make it a secure property to avoid it to apear on the installer logs.
Add the value to the Web.config: Now that you have the key, you can use some of the wix custom actions to modify the web.config, you can use XmlConfig or XmlFile. With this you will be able to modify the Xml file to add the machineKey node using the property created on the previous step. Review the links below for reference on how to use these to update the configuration file.
IMPORTANT: The machineKey element is only valid in the Web.config file at the root of your application and is not valid at the subfolder level.
Additional links:
Adding a Custom Action
Editing Web.Config Connection string settings with Wix
Custom actions with C#
How to pass parameters to the custom action?
Related
I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here
is it possible to set some values in the Web.config file via the Properties.Settings.Default... settings in a asp.net project?
EDIT: I know how to create the settings. but my question is: can I use them directly inside the XML of the webConfig. e.g. I devine a setting called database and then I use this variable inside the connection string in the web.config
I have a web service reference in a ASP.NET 2.0 web site project. I'd like to be able to switch between staging and production versions of the service without having to change my code.
However, I'm not seeing how to do that in a clean way. I know that I can change web.config to point to some other service URL, but then isn't my code still hard-coded to one reference or the other?
I saw this post, but how do you edit the proxy class? If I "Go to Definition" on the class, it doesn't take me to any class that I can edit, but it's the object browser... Do I need to run the wsdl.exe utility so that it will generate a proxy class for me that I can then edit?
Edit #1: Here's the code I'm using to instantiate and call the service:
Dim service As New Swan.MagellanLeadSheetService()
Dim response As Swan.MagellanLeadSheetResponse = service.Foo(stuffToSendToService)
Edit #2: Since the web.config already has the URL endpoint address in the appSettings area, can I just simply edit that setting when we deploy to Production to point to the production URL? Is it that simple? I was worried about the potential for breaking changes between the proxy classes of Staging vs. Production, but those should be resolved prior to deploying any changes to Production I think.
The following article explains how you can make the Web Service Reference dynamic by changing the reference properties, adding a key to the web.config file and referencing this key on the application code:
Article Link
Basically you will have 2 versions of web.config file, production and staging with different URLs defined. While the code will point to a unique location.
UPDATE:
Now, before the following line, you have to alter the service.URL according to what stands in the web.config.
Dim response As Swan.MagellanLeadSheetResponse = service.Foo(stuffToSendToService)
First of all here is some info how to add a web reference to your project:
How to: Add and Remove Web References
Then instance of your webservice class (the proxy class that derives from SoapHttpClientProtocol) has to have an property called url, with that property you can swith at runtime to your asmx from staging or production.
CountryService service = new CountryService();
service.Url = "http://foo/bar.asmx";
More info: WebClientProtocol.Url Property
I have an application which creates page routes from a database. My whole site is secured with forms authentication but I need to allow unauthenticated uses to access these routes. I don't want to hard-code <location> tags for the routes in the web.config as this will negate me using a database to generate the routes.
Can anyone help?
Thanks everyone. I've found an answer here
Basically it involves creating a folder for each route and putting a web.config file in it allowing access. This approach needs to be coupled with setting RouteExistingFiles to false so that the routes don't get confused with the folders.
Rather than using strongly typed configuration classes, why not make the modifications directly in XML?
Here's an abbreviated snippet to demonstrate the concept from some code of mine that performance IIS tuning in the machine.config. The principal is the same for other XML config files though. You just need to create the appropriate XPath statements to do what you need.
XmlDocument machineConfigFile = new XmlDocument();
machineConfigFile.Load(MachineConfigPathString);
XmlNode autoConfig = machineConfigFile.SelectSingleNode(#"/configuration/system.web/processModel/#autoConfig");
autoConfig.Value = "false";
machineConfigFile.Save(MachineConfigPathString);
When saved, the XmlDocument object will preserve all other untouched document nodes. Very handy. It works great for modifying the machine.config. The only possible issue I can see is that your application will probably reset when you save your changes to the web.config. So test it out in a safe environment with a backup of your web.config just in case the reset causes any undesired outcomes!
I found this MSDN link for you. I didn't find whether you can modify the config of running server instance this way though.
Have you considered implimenting your site security in a different way? Having a portion of the site that allows unauthenticated access and a portion that does not. I am "assuming" (bad) that you are using MVC since you are describing routes - this is very easy to do with both MVC and traditional web form applications.
I've been reading others questions regarding storing settings in the web.config. Most of you agree that's a good way to store settings.
I just have another doubt about that.
In my app, I need to map some ID's in the web.config. For example:
[Table = UserType]
1 - User
/2 - Admin
Is it a good idea to store these settings in the web.config so I know what is the right ID in my application? Do you have a better solution?
Thanks guys,
G
If that values doesn't change too often, it's better to create a enum to store that values. An enum sample could be:
enum UserType
{
User = 1,
Admin = 2
}
For more options, also take a look into [Flags] attribute: Enums, Flags, and C# — Oh my! (bad pun…)
Keep in mind every time you edit your web.config file, your IIS application pool get recycled.
I typically use the web.config to store things like connection strings, or key/value pairs that rarely [or never] change.
What you described would be ideal for an enum or perhaps a look up table in the database.
In my web application I have a number of "Configuration" settings that exceed the structure of the Web.Config file, and don't want the web site to restart after changing them.
I ended up creating a number of xml config files where the xml data maps to objects that get cached into collections. This allows us to change the config on the fly, while not restarting the web site. We have a filewatcher that triggers a reload of the cache objects from the Xml files when something in the configuration directory gets modified.
You can also use the database for this obviously, but in our case this was configuration data that is maintained by development and deployed with the build.