Is it possible to completely negate a web.config in a subfolder?
Obviously, I have a web.config in the root.
If I have a subfolder called "MyApp", can I write a bunch of code in there and have it run without any reference to the web.config at root? It would have its own web.config, and wouldn't even reference the "higher" web.config in root.
What I'm looking for is complete App isolation. I'd like to be able to write an app in a subfolder of an existing site, which ignores the entire web.config hierarchy above it -- the app would an island all to itself.
I know I can use the "clear" element, but is that the best way? Just put a "clear" under every top level element? Just wondering if there's another way.
Duplicate of Will a child application inherit from its parent web.config?
On the web.config file in the root directory, wrap the <system.web> element with the following element: <location path="." inheritInChildApplications="false"></location>
Check out this link for a reference:
http://www.jaylee.org/post/2008/03/Prevent-ASPNET-webconfig-inheritance-and-inheritInChildApplications-attribute.aspx
Yes, you have to clear those sections want to override. Thinking about it a bit more, this makes sense, as the only way to clear everything might make it very hard to work out what to clear it to. Clear normally resets everything, including the root web.configs in the web.configs and machine.config defined in the frameworks /config folder on your server.
Note that you'll also lose access to the /bin folder, /app_code folder, etc. This may or may not be what you want.
Whether you can create sub-applications with your host is another matter to consider as well.
No. By design for shared hosting and simplicity sake.
IIS7 changes that a little by allowing the configs to be explicitly locked/unlocked.
It sounds more like you should create a virtual directory that is another application root entirely.
I've just come across this issue in my work and my solution was to create a new website, instead of trying to nest my application under the existing website. I kept the domain mapping the same for the new application (i.e. www.mysite.com ) but changed the port number/mapping.
As a result I can use my new app on www.mysite.com:88 and didn't have to use a subdomain.
The caveat here is that my application is a web service so having to specify the port number in the URL was a possibility for me. It might not be an option for you but I thought I would post this incase it helps someone in my situation.
The <location path="." inheritInChildApplications="false"></location> solution wasn't an option for me as the inheritInChildApplications doesn't seem to exist before ASP.Net Framework 4.0?
Related
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 have a few applications that are set up using elmah for error handling. I recently read that Web.config files inherit from parent applications/directories, and decided to test it so that I can change elmah's settings in one place (since all the current Web.configs are identical when it comes to the elmah configuration). After creating a virtual directory in IIS7, nesting all my applications under it, and creating a stand-alone Web.config file in the physical folder, I tried testing it.
After removing the elmah specific configurations from one of the applications, I found that elmah stops working altogether. Just to see if it was something I did wrong, I created a connection string in the parent Web.config file, then called the connection string through code in the application. No issues. Inheritance was working fine. I tried adding all the elmah specific configurations back in, and removing them one at a time, but it kept complaining every time I removed something.
The question I have is:
Can only certain settings be inherited from the parent Web.config?
If not, am I just not comprehending how inheritance works with nested Web-configs?
I wanted to ask if it's an issue with me before I ask about it on the elmah site.
You should check this answer, it will maybe help you.
Also, in your child web.config, make sure that you do copy the configsections for Elmah (or make sure they are properly inherited). Otherwise, the elmah sections in your child web.config might not work (not entirely sure about that though)
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.
URL authorization only applies to Asp.Net related file types?1 But why couldn’t it also be applied to non-Asp.Net file types?
Thanx
This is because of the script maps for ASP.NET. Only certain extensions are mapped into ASP.NET. The rest are handled directly by IIS. This is by design, for performance reasons.
There are two ways to handle this.
Duplicate your authorization rules in the web.config files in NTFS File ACLs (that is, set permissions on folders and files directly). Make sure that the user's authentication scheme matches the accounts and groups used for controlling access... in other words, if you're using SQL to store username tokens, this won't work, because those tokens won't necessarily map back to domain users and groups/roles.
Create an IHttpHandler to serve up your non-ASP.NET files. From the ProcessRequest method, call the Server.MapPath(url) method on the incoming URL, then stream out the file using Response.WriteFile(filename). You will probably need to set the ContentType property first. And, (here's the bad news), you may still need to perform a declarative or imperative access check -- just having the entries in the web.config files may not work. See Custom ASP.NET Processing with HTTP for more information on writing your own handler. It's probably a good idea to make separate handlers for each content type. Once you've written one, you'll see how easy they are to make.
You could try (haven't tried this myself) to add <httpHandlers> elements to web.config files where you have additional <authorization> elements -- use the <remove> element to remove the inherited HttpHandler and add another one at the subfolder level (perhaps pointing back to the same class?). I'm not sure this will work, but it's worth a try.
Finally, if you really don't want to go through and do all this work, you could simply add more extension mappings in IIS. For example, take a look at How to: Register HTTP Handlers, you can add a mapping for .jpg files to the aspnet_isapi.dll (take a look at the existing mappings for .aspx and so on). You do not need to add an HttpHandler element to your web.config, because the machine level web.config already contains this entry:
<add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler" validate="true"/>
Please note that this may have very serious performance issues on your site.
I have an ASP.NET web application where i am having multiple subrirectories in the root folder.in my root web.config, i have sessionMode as "StateServer" . So in one page of my subdirectory, i am not able to do serialization. If i change the SessionMode method to "InProc" , it will work fine. I want to maintain the web.config file in the root directory as it is.So i am planning about having another web.config file in sub directory.Can anyone tell me how to do this ?
Thanks in advance
While you can have a Web.config in every subdirectory not all settings are allowed at all levels.
And SessionMode is one setting that can only be made in the application-root.
You can just place a new web.config file in the sub-directory and ASP.NET will override any settings you change in that directory.
If you mark the class that is being put in the Session with the [Serializable] attribute, it can usually be used in an StateServer setup.
Just put another web.config in the subdirectory. ASP.NET allows for that, and I have several areas on my website where the web.config contains values specifically for that "application" specifically.
That said:
1) Are you sure it's a good idea to maintain state in two different ways? It would probably be better to figure out how to make your session state serializable or get rid of using session state altogether.
2) All those web.config files can get tough to maintain if you're not careful about what values you put in each.