The SettingsFileGenerator.xml file seems to have two purposes. One is to set the SSO Config and the other is to dynamically replace settings in the PortBindingsMaster.xml for each environment. I am replacing dozens of values in the PortBindingMaster.xml file that don't need to also be stored in the SSO config. Is there a standard way to specify which settings I want to be stored in the SSO config so I don't store a lot of extra values there?
Unfortunately, what you're asking is not directly supported. There a couple of workarounds though.
You can maintain a separate settings file for runtime only settings and use a custom CustomPostDeployTarget task to Exec SSOSettingsFileImport.exe with you runtime settings file.
Or, you can use a set of UpdateSSOConfigItem elements as referenced here: Deploy Configuration Settings into SSO.
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 there ever a case that the traditional ASP.NET appSettings should be preferred over a Sitecore setting (i.e. <configuration><sitecore><settings><setting>) when creating application-specific settings? I can think of a couple of advantages of using Sitecore settings, for instance, being able pull those setting out into the App_Settings/Include folder, but I am not sure of any advantages of using the ASP.NET appSettings.
I would suggest a third approach. I highly recommend creating a configuration file, and corresponding IConfigurationSectionHandler, specific to your project (or assembly). This prevents appSettings or sitecore/settings from becoming a dumping ground and prevents magic strings (i.e. the configuration key) being littered in your code. This approach also allows developers to quickly identify where settings are for code in a specific assembly (the config file should be named similar to the assembly). Furthermore, using Slow Cheetah you are able to add configuration transformations to the file.
I dislike the use of appSettings for anything other than settings which are very specific to the web application project itself. Examples would be aspnet:MaxHttpCollectionKeys as Trayek mentioned, ClientValidationEnabled or UnobtrusiveJavaScriptEnabled
In a similar vein, I dislike the use of Sitecore settings for anything other than storing settings for Sitecore modules or other customizations to the Sitecore system.
I think the advantage to the Sitecore configuration route is as you describe. Namely, your settings can be segregated into their own .config file in App_Settings/Include. Moving settings outside of web.config is somewhat possible natively via the configSource attribute, but Sitecore allows for as many files as you need. That way each component's settings can be contained in their own file (and distributed as such).
The other advantage is being able to take advantage of Sitecore's config patching mechanism. If a your component installs a default settings file, but a certain environment needs to override a value, you can put a second file in place to override the values.
We are also using the Sitecore settings for our configurations. Another advantage is that you have a nice interface to read the properties:
Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);
The only disadvantage I can think of is, that the files in the Inlude-folder will be rendered at runtime and the settings in the web.config not. So if you have thousands of settings you may consider to add them to the web.config.
In our projects we tend to have the global settings, such as the URL to use to get address information, in the appSettings.config and the Sitecore specific settings in the Sitecore settings.
I think it's mainly a matter of preference, although I think there might be settings that can only be added to the <appsettings>, such as aspnet:MaxHttpCollectionKeys (I haven't tested adding it to the Sitecore settings though).
Going on Kevin's disadvantage (at least, how I understand it), is that you can't quickly see what settings you're using - you can go to website/sitecore/admin/showconfig.aspx for that (although that only gives you the <sitecore>...</sitecore> section of the web.config.
The advantage of appSettings is that it'll run out of the box anywhere, and it's dead simple. Everyone who knows ASP.NET knows what appSettings are. While Sean Kearney offers some good advice, I feel it's a bit of a violation of the K.I.S.S. rule. You already have two different options for configuration settings... why add a third? This seems quite unnecessary, unless you are dealing with hundreds of settings.
You can quickly and easily make appSettings more manageable by putting it in its own file.
I would like to store some meta-information about a given site instance that can (a) be managed by that site instance and (b) persist clobbering of Web.config file.
The site will run in multiple environments (dev,testing,staging and production) and each environment can have different values for this metadata.
Note: All environments are running IIS 7.0+
The Root Web.config seems very appealing, as it is certainly outside of the website. Therefore, both files and databases can be changed while maintaining the metadata. I have seen how to modify the appSettings of the Web.config stored in the website, but is it possible to similarly modify the appSettings in the Root Web.config (Specifically within the proper directive)?
If you have other suggestions of approaching this problem, I would be very happy to hear them. Thank you!
would not use web.config for runtime modifications, that will cause the application to recycle, perhaps some other form of configuration file like app.config
if my assumption is incorrect and the web.config will not be edited after the application is started, then you can use WebConfigurationManager to access the file sections
Yes you can modufy the app settings within your web.config Just use the WebConfigurationManager class in the System.Web.Configuration namespace to create a Configuration object. This object could then be used to read and write changes to the web.config file.
You could then create your own "keys" or attributes that could be read as needed.
Depending upon what your attributes represent or if they need to be picked up by multiple environmnets from that server I would also look into making the modifications within the machine.config file as then those settings would apply to the enter machine and thereby picked up by multiple environments( if you are hosting multiple webapps from the server). This could save you time in modifying multiple web.config files and narrorw the storage or the metadata to one location vs. multiple config files in certain situations.
When you have a system of multiple application, web services and windows services, which is better option?
Option 1) Put all settings in database table and cache it somewhere, probably you will have to use a web service to share the cache object across applications. You can then view some of those settings in a grid for user manipulation.
Option 2) Put all settings in a common configuration file, and let web.config or app.config of each application points to that file, I am sure there is a way to put those settings in a grid, but probably you will lose the capability of "showing settings based on Role".
Thanks
A lot of this comes down to preference, what settings you're talking about, when you need access to the settings, and how often they'll change.
Generally, I try and keep my web.config & app.config pretty small. Settings for infrastructural things (e.g. modules to load, connectionstrings, log settings, ORM settings, etc) go in there. Anything that I really need or want to have access to on App_start or in my Main() method, basically.
Anything more complex, or that's applicable to less of the application, etc, I generally don't put in the config files, but instead either have settings objects which I inject through my IoC container, or else pull them from a database.
I prefer option 1, as it makes deployments easier, as each environment can have different configurations, yet you're still able to do a xcopy deploy, as settings aren't stored in the web.config.
I would suggest putting the configuration in the database and then retrieving it based on the application. You can also write a single XML that contains different configurations and load it on the datagrid etc..This way management of the configuration becomes easier, because you have a single file to maintain.
I have few settings which I could place in a separate XML file and have them accessed in the Web app. Then I thought (thinking of one additional file to deploy), why not have them in the web.config itself. However, just because I need to have custom nodes, I can not have the settings under . So, I am thinking of creating a custom config handler following this. Would that be better than having a separate XML file? Is It going to be an overkill or performance wise? Is there a better way to go?
From performance standpoint putting custom settings in web.config and creating a configuration handler will be OK because the config values are cached and read only once when the application starts. Putting the values in a separate XML file you will need to handle the caching your self if you want to avoid parsing it every time you need to access those values.