In my last post I described a way to set up a web service. One of the requirements of the service was that it could share some of it's settings with a web site. In a first attempt I made the service part of the site, so it would use the same web.config file, creating a single point of configuration for things like the db connection strings contained. For a lot of other reasons this was a bad idea. The service became a separate project, that is a separate application on the web server, with it's own web.config.
The good thing is that ASP.NET does share information in a web.config by default. When starting the application, that is on the first request of the session, IIS reads in the web.config of the application and all other web.config's up in the tree of applications on the server. It combines them into one list of settings. So when the service is in a subfolder of the site, all the site settings are available to the service.
In this case IndatoService can read all settings of Indato. When combining these settings asp.net does something you can compare to overriding. In the web.config of the site authentication is set to forms authentication, directing the user to the login.aspx page.
For a web service forms authentication will not work. The web.config of the service will also set an authentication method more fit to a service; this setting overrides the setting in the site's web.config.
<!-- AUTHENTICATION This section sets the authentication policies of the application. Possible modes are "Windows", "Forms", "Passport" and "None" "None" No authentication is performed. "Windows" IIS performs authentication (Basic, Digest, or Integrated Windows) according to its settings for the application. Anonymous access must be disabled in IIS. "Forms" You provide a custom form (Web page) for users to enter their credentials, and then you authenticate them in your application. A user credential token is stored in a cookie. "Passport" Authentication is performed via a centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites. --> <authentication mode="Windows" />
Note that the comments in the web.config generated by the Visual Studio web service template include the suggestion to use forms authentication while it makes no sense for a web service. The web.config generated by WSCF does not include any authentication settings; the WSCF service will "inherit" the authentication used by the application up in the tree.
So settings in a web.config can span more than just the application it's part off. But you can also limit the settings to a narrower scope. All settings in the web.config are between the <system.web> tags. To have different settings for a part of an application you repeat this <system.web> part enclosed in tags for the specific location. Take authorization. In this example the Tabellen folder is closed for everybody by adding a section, which will something like this:
will produce a somewhat cryptic error message. It will pop up when you try to browse to a page in the Tabellen folder.
The message may be cryptic but it points exactly to the line in config.sys which caused the trouble.
In case you are afraid another application will install in a subfolder of yours and hack your configuration settings you can use the allowOverride attribute. The attribute can be applied on a lot of tags.
There is so much more you can do with the web.config file. For a good overview I can recommend ASP.NET setup and configuration by James Avery (MS press); a handy little book explaining settings with good code samples. The link invites you to read the book online but does not lead to anything useful.
Previous Topic
