I created a set of ASP pages which receive HTTP requests. Some of these requests pull data from a database, and few of them open text files to get info. My path to these text files are pretty straight-forward on my web server, and I refer to these in my web.config as below in the appSettings node.
<add key="MasterPath" value="C:\inetpub\wwwroot\VecoXtra\" />
However, my client (who is going to use this) has set up my scripts on their server but wants to use a UNC path to these files, and the process stops when changing it to:
<add key="MasterPath" value="\\10.10.6.2\euro$\INETPUB\VeXtra\StaticFiles\" />
I read somewhere to double up the slashes, but to no avail, as I think there are some permissions issues here. I tried identity in my config and adding my windows administrator login to the application pool but nothing allows me to access these files.
I changed the Applcation Pool AND the setting to load profile to true and it kicked into gear.. thanks for letting me talk it through :)
Related
Current installation
I have two web applications app_A and app_B (same app with app_A but for test purposes) under IIS default website. A domain www.mydomain.com that points to the server needs to access app_A. That can be done by changing the physical path from \inetpub\wwwroot\ to \inetpub\wwwroot\app_A.
The second application should be access under www.mydomain.com/app_B/
Problem
When accessing www.mydomain.com/app_B/ because it's now a sub-directory of app_A it sees the web.config from app_A and I got error like "duplicate entries in web.config" when accessing the www.mydomain.com/app_B/ application. I can eliminate the errors by using the tag to remove first and declare again the entries in app_B web.config.
Questions
Is there any other way to make the installation in order app_A would be access from www.mydomain.com/ and app_B from www.mydomain.com/app_B without messing the web.config files as described above?
For the current installation, is there a way to set something on IIS in order for app_B not to see at all web.config from app_A because is a subdirectory?
For the current installation, do you see any real problems (possibly on security) by using the remove tag for the app_B application?
For the current installation I observer a strange behaviour. If I login to app_A and app_B and logout from app_A it also logout from app_B (not always). I am using Active Directory for authentication. Do I need to change something in app_B's web.config in order to say that it's totally different application?
I know this is an old question and you might have found out the solution. I am replying in case you need an answer.
There are two ways to avoid merging of parent’s config file and child’s config file. Either you can add
inheritInChildApplications="false" Tag in the parent’s config file. For example:
<location path="." inheritInChildApplications="false">
<connectionStrings>
</connectionStrings>
</location>
Or
you can add "Remove" tag or "Clear" in child’s config file to clear the parent’s settings.
Also, I don’t see any security threats by clearing parents settings.
By any chance are you using same cookie name in authentication for parent and child applications? If this is the case, once you login to child application, the cookie generated by the parent application will be overridden. Try specifying name of the cookie for at least one of the application.
I've got a website which has a virtual directory that also includes a website, and when I try to launch a page from the virtual directory, I receive an IIS 7.5 error that the name (from the connection string) is already in the collection. This wasn't a problem before I added a domain user as the Identity in the app pool. Does anyone know why this is happening? I was under the impression that sub level application's web.config overrides the parent's by default. And again, this was once working until I added a custom Identity.
The error on the page is "Parser Error Message: The entry 'dbname' has already been added."
Where the dbname is in both connection strings (i.e. parent and virtual directory). I can't delete one of the connection strings because the virtual directory is only created for test purposes, but in production it runs as its own website.
A sub web.config doesn't override a parent regardless of application. All web.configs will stack up all the way to the root of the primary application. In order for sub-application folder to make use of a connection string key that is already in use it must first be removed or all connection strings must be cleared. If you want this to be a truly stand alone application as a child add this to your connection strings:
<connectionStrings>
<clear />
<your connection string>
<connectionStrings>
If you just want to remove the single connection string use this:
<remove key="yourConnectionStringName" />
#u84six,
Today this had happened to me.
I had some websites and webservices in the same root website. The root is the default iis website (Default Web Site) and i think it was pointing to C:\Inetpub\wwwroot. Its a development environment.
After i read this answer, i found out that one of my webservices was the root website (still not sure what changed it... maybe visual studio after a migration from 2010 to 2012). That webservice was using the connectionString in conflict. I change the path back to C:\Inetpub\wwwroot\ and everything went to normal.
Maybe something similar happened to you.
if it is cached, what happens if I use multiple web.config in multi-level folders
They all get cached.
Configuration is read once, at startup. With web.config, IIS watches for file changes and restarts the application.
OK, so ya'll are missing a KEY feature in the Web.Config file's area.
Yes, web.config is cached and changing contents of the file will restart your web app. And, all your connected users will not be happy, too, because they'll need to "reconnect" a-new, possibly losing desired information.
So, use an EXTERNAL custom file for your AppSettings, as follows:
<appSettings configSource="MyCustom_AppSettings.config"/>
Then, in the file MyCustom_AppSettings.config file, you have your settings, as such this example has:
<appSettings>
<!-- AppSecurity Settings -->
<add key="AppStatus_Active" value="Active"/>
<!-- Application Info Settings -->
<add key="AppID" value="25"/>
<add key="AppName" value="MyCoolApp"/>
<add key="AppVersion" value="20120307_162344"/>
</appSettings>
Now, if you need to add, change, or remove an AppSetting, when you change it in this file the change is nearly instant in your web-app BUT (and here's the BEST part), your app DOES NOT RESTART!
Everything stays kosher except those settings you've added/modified/removed in the external .config file.
And, yes, the same thing can done for the section as follows:
<connectionStrings configSource="MyCustomApp_ConnectionStrings.config"/>
and the file MyCustomApp_ConnectionStrings.config has all the connection strings you need. Change a connection string in the external .config file and it starts getting used right away and with no web-app restart.
The configSource setting(s) are great when you need to deploy to development, testing, and production on different boxes and need settings pertinent to that given box/environment.
So, now ya know (something that's been around for 7+ years).
It's That Simple. Really.
KC
Web.config (excluding external config files) is read when the application loads. Some config settings have a cascading behavior. For example, the system.web/authorization section can be overridden by configs at deeper levels.
ASP.NET monitors the web.config for changes. When it changes, the web application is forced to restart. Moral is that web.config settings are cached for the life of the application.
I have IIS 7.0 on my development machine and IIS 6.0 on my server. On my development machine I was able to set a handler map on a directory within my site called /ViewHtml/ and I mapped it to asp.net. In my global.asax I check the request sent to asp.net for /ViewHtml/ and I serve the appropriate html file(html version of a Doc, Power Point, or Excel file) located outside this apps virtual directory. I am doing it this way because all files are permission protected, we didn't want to put these files in are database due to scalability, and I need to hide the path to these file on the server. This all works in IIS 7.0 exactly how I would like it to. Although I have not been able to get my IIS 6.0 server configured to map all requests to that directory to asp.net.
Any ideas? Thanks Guys?
I set up a web application using the same configuration you're using and I'm also getting the 404. I don't know why it works in IIS 7, but here's what I had to do to fix it.
Create a class that implements the System.Web.IHttpHandler class. move the the code from Application_BeginRequest to your implementation of IHttpHandler.ProcessRequest.
Now you just have to register your HTTP handler with ASP.NET. To do so add an entry in your Web.config at /configuration/system.web/httphandlers.
Web.config Example:
...
<httpHandlers>
<clear />
<add verb="*" path="*" type="namespace.classname, assemblyname" />
</httpHandlers>
...
That entry is telling ASP.NET to handle HTTP requests with any extension and any HTTP method by running the code in your HTTP hander. Note that I'm also clearing all the previously definded handlers (defined in the machine's web.config).
Note that you will still need the Application Mapping configured in IIS.
If I understand the problem correctly, it sounds like you need add a "Wildcard Application Mapping" for your virtual directory. In other words, you want to forward all requests to any file extension to ASP.NET's ISAPI extension.
To do so, open the properties of your virtual directory. On the Virtual Directory tab (Home Directory tab if it's a web site), click the Configuration... button. Click the Insert... button next to the bottom list box in the dialog that shows up. In this dialog, choose "%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" as the executable and make sure to un-check "Verify that file exists" checkbox, since the files to be requested don't live in your virtual directory.
I hope this helps!
i think your problem is all about access policy , you have to make sure that the access policy is Read and not None , cz with None you have no permission to even read files from your website
On Apache/PHP sites if I want to put a senstive file within my website folders, I put a .htaccess file in that folder so users can't download the sensitive file.
Is there a similar practice for IIS/ASP.NET sites, i.e. if I have a shared hosting account and don't have access to IIS server. Can I do this in web.config for instance?
e.g. the ASPNETDB.MDF file that ASP.NET Configuration put in the App_Data directory. I would assume this is protected by default but where can I change the settings for this folder as I could with a .htaccess file?
Inside of an ASP.Net web.config you can setup locations to add security to specific files and folders. In addition, you can remove all verbs from those directories:
<location path="Secret" allowOverride="false">
<system.web>
<authorization>
<deny users="*" />
</authorization>
<httpHandlers>
<remove path="*.*" verb="*"/>
</httpHandlers>
</system.web>
</location>
I have only used the authorization portion of that snippet and it works great. The handler should further lock it down and using a ISAPI filter would be able to put the finishing touches on it.
Well, if you can access IIS settings, UrlScan can help. For IIS 7, request filtering can help a lot.
http://learn.iis.net/page.aspx/473/using-urlscan
http://learn.iis.net/page.aspx/143/how-to-use-request-filtering/
There are some things you can do with web.config like defining security settings etc...
Other times you have to use HttpModules or HttpHandlers, look here:
http://msdn.microsoft.com/en-us/library/aa719858(VS.71).aspx
If not, you can find different ISAPI, but in this case you need access to IIS.
For example, the ISAPI for emulating rewrite mod apache:
> http://www.codeplex.com/IIRF
The other question, yes ASPNETDB.MDF in APP_Data is protected normally (it depends on your administrator). To change the path, change the connectionstring.
There are two cases:
If the server is using IIS7 then there is equivalent functionality available using the web.config approach for all files.
If the server is using IIS6 or earlier (and for the time being this is by far the most likely case for shared hosting) then its more of a problem. If you can force all your requests to go via the ASP.NET handler (which normally requires access to the server to configure) then again the web.config approach will work but otherwise you're going to need other tools and a sympathetic hosting provider. For this reason alone one probably wants IIS7...
That said for asp.net there are files that are protected by default anyway - files in app_data as already mentioned plus specific file types (like .config). Additionally one would expect a decent host to provide a directory that is not accessible via the web - ours offer a private and a web folder, both accessible via FTP but only the contents of the latter via the web.
As per the [documentation on Application Folders][1], IIS won't serve requests to content stored in the /app_data folder although your application can read and interact with those files.
ASP.NET recognizes certain folder names that you can use for specific types of content. The following table lists the reserved folder names and the type of files that the folders typically contain.
Note
The content of application folders, except for the App_Themes folder, is not served in response to Web requests, but it can be accessed from application code.