I have situation described bellow:
In CMS was implemented two presentation server which aren't on same machine. Client want to enable IIS caching only on one machine, but changing manually web.config isn't suggested. So I am planning to make some C# code which will make changes in web.config in order to ensure proper cache settings. Is it possible or exist any other solution ( change other settings, edit other files...) for the problem?
"You can configure the element at the server level in the ApplicationHost.config file or at the site, application, or at the directory level in a Web.config file."
If you have physical access to the server you can run from the console appcmd.exe:
appcmd.exe set config -section:system.webServer/caching /+"profiles.[extension='asp',policy='CacheUntilChange',kernelCachePolicy='CacheUntilChange']" /commit:apphost
Check this link: http://www.iis.net/ConfigReference/system.webServer/caching
EDITED
The first answer to this question says how to configure caching at folder level, the 2nd answer for file level:
How to configure static content cache per folder and extension in IIS7?
If you didn't specify any caching rules at file or folder level, disabling global caching should do it.
Related
I have doubt on storing web.config files in Git-hub, is it recommended?
Is this not a security vulnerability?
Also web.config for different environments will be different in different enviroments, hence how to keep different versions of web.config is same repo and branch?
Yes, it is.
Use server-level secrets to store sensitive information like DB connection strings.
In IIS you can use ASPNET_REGIIS - it lets you add secret configuration that IIS can access, but that isn't held in plain text with the web files.
In .NET core there's new Microsoft.Extensions.SecretManager.Tools that does the same thing.
For different environments you can have multiple web.config files, for instance web.release.config and web.debug.config.
Your web.config file itself is not a security issue. The keys you probably have inside it like connections strings are indeed very much sensitive and should not be in version control. The problem is how to manage those keys without having them in the web.config (or any other version controlled settings/config file).
Keith is correct that you should use server-level secrets. If your managing the server yourself you can use his method of setting them but if your using a service you'll need to set the keys up however they specify.
An example on Azure
How and where to define an environment variable on azure
Another on Heroku
https://devcenter.heroku.com/articles/config-vars
Setting up the server-level secrets is only the first step. Once you've pulled the keys out of the web.config you'll have to set them up locally. Here's a blog post that talks about setting them using your local machine.config.
http://krow.tech/posts/Keeping-Your-Secret-Configs-Private
I am creating a .exe to install my MVC application on to client's servers. It downloads zip file from the internet, extracts all files into the correct places, updates the web.config file to include all the correct app keys.
The problem that I am having is that IIS doesn't have permissions to read web.config so I get a HTTP Error 500.19.
I know that I can just give instructions to the installer that tell them to add the permissions manually, but that looks a bit cheap.
So, in C#, what can I do at the end of my installer to allow IIS to read my web.config file and really everything else in my site.
I know that I can just give instructions to the installer that tell them to add the permissions manually, but that looks a bit cheap.
I dont really think that this is a bad idea. All webfiles must be accessable from the user IIS_IUSRS of the local server/computer. If they dont have this permission, you get access problems like you state it above.
I suggest you to take a look on the FileSecurity class of C#. You will be able to set file permissions, even if it´s only for the web.config.
What is the purpose of having two files that appear to do the same/similar thing? Is one deprecated and should I be using the other? Please, break it down for me.
Thanks!
Check Settings file -v- app.config.
Implementation.
An application can provide an interface for the user to edit/modify setting that can be persisted. There is no API to write to app.config and nothing to re-load it should it be changed at run-time. Thus, Settings were created. They provide one place to hold application and user settings. User settings default values are stored in app.config that the user can edit before the application is run; but should the application provide an interface to edit/modify certain settings they can be persisted back to disk to a user.settings file local to the user allowing users to have independent and secure setting values
The first one stores application specific settings (global) and the second one stores setting per user.
An application configuration file is meant to go in your application's working directory as .exe.config. A settings file goes in the application data path to store settings. Typically, you use a Settings file for user-level settings that are different for each user running it and don't require elevated privileges to modify.
I need to allow my asp.net application to read and write from and to a folder.
Could you please help me to do so.
Regards,
Assuming your application pool is using the default identity (it probably is), then right click on the folder, select Properties, go to the Security tab, click Edit..., click Add..., in the object names field enter NETWORK SERVICE (also assuming IIS 6 or 7 here), click OK, in the permissions pane check Write, and click Apply.
That should do it.
It's two pronged, neither of which involves your code, and both assume you have access to server settings. You need to have appropriate permissions set on the folder in the file system as well as within the IIS web application.
How do I engineer failover logic properly if an Assembly (.dll) cannot find a web.config file?
Background: I've got our website code nicely modularized into two different .dlls. For simplicity's sake, let's call them:
website.dll
commonengine.dll
The website code and .aspx / .ascx files calls upon the commonengine library for all data layer stuff. For connection strings, the commonengine in turn looks not to the app.config but to the website's web.config file (that's my own preference -- I prefer to have our production constants all in one place). The website code occasionally (very rarely) needs to access stuff in that web.config file. All good so far (even though not entirely pure).
Here's the trouble. I've written a third module. It's a Windows Service (specifically, it's a POP3 checker/processor -- processing mailbox requests and using the commonengine.dll for some data layer stuff).
The problem is the Windows Service calls upon the commonengine.dll, and the commonengine.dll cannot find web.config anywhere because, after all, it's a Windows service (.exe) and doesn't live in a website directory.
What's the proper test/logic here to use app.config when a web.config file cannot be found? Can any ASP.NET configuration gurus give me some guidance here? Thanks much if so.
I never read Web.config explicitly, I use the System.Configuration class to read it (e.g. System.Configuration.ConfigurationStrings["conn name"]). It will automatically go to Web.config in an ASP.NET app and app.config in an EXE.
Of course, you still have to take into account the fact that the config section might be missing.