IIS

In which process does IIS runs (was asking about the EXE file)

inetinfo.exe is the Microsoft IIS server running, handling ASP.NET requests among other things. When an ASP.NET request is received (usually a file with .aspx extension), the ISAPI filter aspnet_isapi.dll takes care of it by passing the request to the actual worker process aspnet_wp.exe.

Where are the IIS log files stored?

C:\WINDOWS\system32\Logfiles\W3SVC1
OR
c:\winnt\system32\LogFiles\W3SVC1


What are the different IIS authentication modes in IIS 5.0 and Explain? Difference between basic and digest authentication modes?

IIS provides a variety of authentication schemes:
• Anonymous (enabled by default)
• Basic
• Digest
• Integrated Windows authentication (enabled by default)
• Client Certificate Mapping
Anonymous

Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. Although listed as an authentication scheme, it is not technically performing any client authentication because the client is not required to supply any credentials. Instead, IIS provides stored credentials to Windows using a special user account, IUSR_machinename. By default, IIS controls the password for this account. Whether or not IIS controls the password affects the permissions the anonymous user has. When IIS controls the password, a sub authentication DLL (iissuba.dll) authenticates the user using a network logon. The function of this DLL is to validate the password supplied by IIS and to inform Windows that the password is valid, thereby authenticating the client. However, it does not actually provide a password to Windows. When IIS does not control the password, IIS calls the LogonUser() API in Windows and provides the account name, password and domain name to log on the user using a local logon. After the logon, IIS caches the security token and impersonates the account. A local logon makes it possible for the anonymous user to access network resources, whereas a network logon does not.

Basic Authentication

IIS Basic authentication as an implementation of the basic authentication scheme found in section 11 of the

HTTP 1.0 specification.

As the specification makes clear, this method is, in and of itself, non-secure. The reason is that Basic authentication assumes a trusted connection between client and server. Thus, the username and password are transmitted in clear text. More specifically, they are transmitted using Base64 encoding, which is trivially easy to decode. This makes Basic authentication the wrong choice to use over a public network on its own.
Basic Authentication is a long-standing standard supported by nearly all browsers. It also imposes no special requirements on the server side -- users can authenticate against any NT domain, or even against accounts on the local machine. With SSL to shelter the security credentials while they are in transmission, you have an authentication solution that is both highly secure and quite flexible.

Digest Authentication

The Digest authentication option was added in Windows 2000 and IIS 5.0. Like Basic authentication, this is an implementation of a technique suggested by Web standards, namely RFC 2069 (superceded by RFC 2617).
Digest authentication also uses a challenge/response model, but it is much more secure than Basic authentication (when used without SSL). It achieves this greater security not by encrypting the secret (the password) before sending it, but rather by following a different design pattern -- one that does not require the client to transmit the password over the wire at all.
Instead of sending the password itself, the client transmits a one-way message digest (a checksum) of the user's password, using (by default) the MD5 algorithm. The server then fetches the password for that user from a Windows 2000 Domain Controller, reruns the checksum algorithm on it, and compares the two digests. If they match, the server knows that the client knows the correct password, even though the password itself was never sent. (If you have ever wondered what the default ISAPI filter "md5filt" that is installed with IIS 5.0 is used for, now you know.

Integrated Windows Authentication

Integrated Windows authentication (formerly known as NTLM authentication and Windows NT Challenge/Response authentication) can use either NTLM or Kerberos V5 authentication and only works with Internet Explorer 2.0 and later.
When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers,

Negotiate and NTLM.

• If Internet Explorer recognizes the Negotiate header, it will choose it because it is listed first. When using Negotiate, the browser will return information for both NTLM and Kerberos. At the server, IIS will use Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 and later, and both are members of the same domain or trusted domains. Otherwise, the server will default to using NTLM.

• If Internet Explorer does not understand Negotiate, it will use NTLM.
So, which mechanism is used depends upon a negotiation between Internet Explorer and IIS.
When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 and later that are trusted and configured for delegation. Delegation enables remote access of resources on behalf of the delegated user.
Integrated Windows authentication is the best authentication scheme in an intranet environment where users have Windows domain accounts, especially when using Kerberos. Integrated Windows authentication, like digest authentication, does not pass the user's password across the network. Instead, a hashed value is exchanged.

Client Certificate Mapping

A certificate is a digitally signed statement that contains information about an entity and the entity's public key, thus binding these two pieces of information together. A trusted organization (or entity) called a Certification Authority (CA) issues a certificate after the CA verifies that the entity is who it says it is. Certificates can contain different types of data. For example, an X.509 certificate includes the format of the certificate, the serial number of the certificate, the algorithm used to sign the certificate, the name of the CA that issued the certificate, the name and public key of the entity requesting the certificate, and the CA's signature. X.509 client certificates simplify authentication for larger user bases because they do not rely on a centralized account database. You can verify a certificate simply by examining the certificate.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconIISAuthentication.asp

How to configure the sites in Web server (IIS)?

Advantages in IIS 6.0?

http://www.microsoft.com/windowsserver2003/iis/evaluation/features/default.mspx
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/datacenter/gs_whatschanged.asp

IIS Isolation Levels?

Internet Information Server introduced the notion "Isolation Level", which is also present in IIS4 under a different name. IIS5 supports three isolation levels, that you can set from the Home Directory tab of the site's
Properties dialog:

• Low (IIS Process): ASP pages run in INetInfo.Exe, the main IIS process, therefore they are executed in-process. This is the fastest setting, and is the default under IIS4. The problem is that if ASP crashes, IIS crashes as well and must be restarted (IIS5 has a reliable restart feature that automatically restarts a server when a fatal error occurs).
• Medium (Pooled): In this case ASP runs in a different process, which makes this setting more reliable: if ASP crashes IIS won't. All the ASP applications at the Medium isolation level share the same process, so you can have a web site running with just two processes (IIS and ASP process). IIS5 is the first Internet Information Server version that supports this setting, which is also the default setting when you create an IIS5 application. Note that an ASP application that runs at this level is run under COM+, so it's hosted in DLLHOST.EXE (and you can see this executable in the Task Manager).
• High (Isolated): Each ASP application runs out-process in its own process space, therefore if an ASP application crashes, neither IIS nor any other ASP application will be affected. The downside is that you consume more memory and resources if the server hosts many ASP applications. Both IIS4 and IIS5 supports this setting: under IIS4 this process runs inside MTS.EXE, while under IIS5 it runs inside DLLHOST.EXE.
When selecting an isolation level for your ASP application, keep in mind that out-process settings - that is, Medium and High - are less efficient than in-process (Low). However, out-process communication has been vastly improved under IIS5, and in fact IIS5's Medium isolation level often deliver better results than IIS4's Low isolation. In practice, you shouldn't set the Low isolation level for an IIS5 application unless you really need to serve hundreds pages per second.
Controls

How will you do Redo and Undo in a TextControl?

How to implement DataGrid in .NET? How would u make a combo-box appear in one column of a DataGrid? What are the ways to show data grid inside a data grid for a master details type of tables? If we write any code for DataGrid methods, what is the access specifier used for that methods in the code behind file and why?

What is ISAPI filter?

In the Internet world, Web servers serve resources that have been put on the Internet and provide other services like security, logging, etc.

At the beginning of the Internet era, clients' needs were very limited; .htm files were often satisfactory. As time passed, however, clients' requirements extended beyond the functionality contained in .htm files or static files.

Developers needed a way to extend or complement the functionality of Web servers. Web server vendors devised different solutions, but they all followed a common theme: "Plug some component into the Web server". All Web server complement technologies allowed developers to create and plug in components for enhancing Web server functionality. Microsoft came up with ISAPI (Internet Server API); Netscape came up with NSAPI (Netscape Server API), etc.

ISAPI is an important technology that allows us to enhance the capabilities of an ISAPI-compliant Web server (IIS is an ISAPI-compliant Web server). The following components serve this purpose:

ISAPI Extensions
ISAPI Filters

ISAPI extensions are implemented by using Win32 DLLs. You can think of an ISAPI extension as a normal application. ISAPI extensions are the target of http requests. That means you must call them to activate them. For example, the following URL calls the store.dll ISAPI extension and passes two values to it:

http://www.myownwebsite.com/Store.dll?sitename=15seconds&location=USA

Think of an ISAPI filter as just that: a filter. It sits between your Web server and the client. Every time a client makes a request to the server, it passes through the filter.

Clients do not specifically target the filter in their requests, rather, clients simply send requests to the Web server, and then the Web server passes that request to the interested filters.

Filters can then modify the request, perform some logging operations, etc.

It was very difficult to implement these components because of the complexities involved. One had to use C/C++ to develop these components, and for many, development in C/C++ is a pain.

So what does ASP.NET offer to harness this functionality? ASP.NET offers HttpHandlers and HttpModules.

Before going into the details of these components, it is worth looking at the flow of http requests as it passes through the HTTP modules and HTTP handlers.

What is server extentions?

http://www.15seconds.com/issue/020417.htm

What is Http Filter and Http Handler?


ASP.NET request processing is based on a pipeline model in which ASP.NET passes http requests to all the modules in the pipeline. Each module receives the http request and has full control over it. The module can play with the request in any way it sees fit. Once the request passes through all of the HTTP modules, it is eventually served by an HTTP handler. The HTTP handler performs some processing on it, and the result again passes through the HTTP modules in the pipeline.

The following figure describes this flow.



Notice that during the processing of an http request, only one HTTP handler will be called, whereas more than one HTTP modules can be called.

Http Handlers

HTTP handlers are the .NET components that implement the System.Web.IHttpHandler interface. Any class that implements the IHttpHandler interface can act as a target for the incoming HTTP requests. HTTP handlers are somewhat similar to ISAPI extensions. One difference between HTTP handlers and ISAPI extensions is that HTTP handlers can be called directly by using their file name in the URL, similar to ISAPI extensions.

HTTP handlers implement the following methods.

Method
Name Description
ProcessRequest This method is actually the heart of all http handlers. This method is called to process http requests.
IsReusable This property is called to determine whether this instance of http handler can be reused for fulfilling another requests of the same type. HTTP handlers can return either true or false in order to specify whether they can be reused.
These classes can be mapped to http requests by using the web.config or machine.config file. Once that is done, ASP.NET will instantiate http handler whenever the corresponding request comes in. We will see how to specify all of these details in web.config and/or machine.config files.
ASP.NET also supports the creation of http handlers by means of the IHttpHandlerFactory interface. ASP.NET provides the capability of routing http requests to an object of the class that implements the IHttpHandlerFactory interface. Here, ASP.NET utilizes the Factory design pattern. This pattern provides an interface for creating families of related objects without specifying their concrete classes. In simple terms, you can consider such a class as a factory that creates http handler objects depending on the parameters passed to it. We don't have to specify a particular http handler class to instantiate; http handler factory takes care of it. The benefit of this is if in the future the implementation of the object that implements the IHttpHandler interface changes, the consuming client is not affected as long as the interface remains the same.
These are following methods in IHttpHandlerFactory interface:
Method Name Description
GetHandler This method is responsible for creating the appropriate handler and returns the reference out to the calling code (the ASP.NET runtime). Handler object returned by this method should implement the IHttpHandler interface.
ReleaseHandler This method is responsible for releasing the http handler once request processing is complete. The implementation of the factory decides what it should do. Factory implementation can either actually destroy the instance or return it to a pool for future requests.
Registering HTTP Handlers and HTTP Handler Factories in Configuration Files
ASP.NET maintains its configuration information in the following configuration files:
 machine.config
 web.config
machine.config file contains the configuration settings that apply to all the Web applications installed on that box.
web.config file is specific to each Web application. Each Web application can have its own web.config file. Any sub directory of a Web application may have its own web.config file; this allows them to override the settings imposed by the parent directories.
We can use and nodes for adding HTTP handlers to our Web applications. In fact the handlers are listed with nodes in between and nodes. Here is a generic example of adding an HTTP handler:





In the above XML,
 The verb attribute specifies the HTTP verbs supported by the handler. If the handler supports all of the HTTP verbs, simply use "*", otherwise list the supported verbs in a comma separated list. So if your handler supports only HTTP GET and POST, then verb attribute will be "GET, POST".
 The path attribute specifies the path or wildcard specification of the files for which this handler will be invoked. For example, if you want your handler to be called only when test.xyz file is requested, then the path attribute will contain "test.xyz"; similarly if you want your handler called for any file having .xyz extension, the path attribute will contain "*.xyz".
 The type attribute specifies the actual type of the handler or handler factory in the form of a combination of namespace, class name and assembly name. ASP.NET runtime first searches the assembly DLL in the application's bin directory and then searches in the Global Assembly Cache (GAC).
Use of HTTP Handlers by the ASP.NET Runtime
Believe it or not, ASP.NET uses HTTP handlers for implementing a lot of its own functionality. ASP.NET uses handlers for processing .aspx, .asmx, .soap and other ASP.NET files.
The following is the snippet from the machine.config file:








. . . . . .
. . . . . .


You can see in the above configuration that all the requests for .aspx files are processed by the System.Web.UI.PageHandlerFactory class. Similarly all the requests for .config and other files, which should not be directly accessible to the clients, are handled by the System.Web.HttpForbiddenHandler class. As you might have already guessed, this class simply returns an error to the client stating that these kinds of files are not served.


ASP.NET v1.1 HTTP Handler Introduction

ASP.NET is Microsoft’s successor to ASP, it’s a dynamic way to generate web pages back to a Web Browser such as Internet Explorer, FireFox and Netscape, using Microsoft. NET. With the advent of the concept of dynamic web pages came the birth of Web Services. A web service is a component that you can access using the HTTP model to send data and commands, normally called messages, to it. If you were to take the abstract of Web Services, it would yield you into the world of Service Oriented Architecture (SOA). ASP.NET Web Services are one way to implement Services in SOA. To keep to the point here, ASP.NET Web Services normally use XML as its format to send and receive messages. Specifically speaking, it uses a SOAP XML format. ASP.NET makes it easy for developers to use this concept to create web services. It has a technology called "ASMX" that allows these SOAP messages to be automatically parsed and generated to access the remote component. ASP.NET implements this and other technologies like this through the use of HTTP Handlers and Soap Extensions (see machine.config snippet).

An ASP.NET HTTP Handler would be equivalent to what an IIS Filter could do (for those C++ developers out there.) The HTTP Handler has the job of handling HTTP Requests and HTTP Responses that come in and out of ASP.NET. It can modify the Response/Request, by adding to it, removing from it, or totally creating a new object of data. An HTTP Handler is usually registered to ASP.NET by the HTTP verb (GET, POST, PUT, etc.), the path (*-all, *.asmx- files ending in .asmx, etc.), and the component that contains the code to execute to modify or parse the Response/Requests (.NET Assembly). This setting is set through an Application’s configuration file. For more robust custom implementations, an ASP.NET HTTP Handler may also need to be registered to IIS, see Watermark Website Images At Runtime by KingLion.

ASP.NET SimpleHandlerFactory

ASP.NET already comes with some HTTP Handlers and HTTP Handler Factories. A HttpHandlerFactory is a class whose job is to create instances of Handlers based off of some logical coded criteria. To create a HttpHandlerFactory, create a class that implements the IHttpHandlerFactory. This class has two methods to implement.

IHttpHandler GetHandler(HttpContext currentcontext, string reqType,
string url, string pathTranslated);
void ReleaseHandler(System.Web.IHttpHandler handlerToRelease);
These factories are registered the same way a HttpHandler is registered, thus I won’t spend too much time on those. We have HttpHandlers that deal with security, such as the FormsAuthenticationHandler. We also have some handlers that deal with restricting access to certain types of files such as the HttpForbiddenHandler. There is also, the all important PageHandler that handles ASP.NET Web Form Pages and the WebServiceHandler that handles .asmx pages (ASP.NET web services). There is also a SimpleHandlerFactory that is mapped/registered to .ashx file extensions. We also have the ability to create our own custom HTTP Handler mapped to our own extensions. (see machine.config snippet)