Yaminij's blog

Session Tracker Native Module for IIS 7.0

yaminij — Wed, 28 Jan 2009 18:47:37 GMT

Overview

The Session Tracker is a native C++ module for IIS 7.0 that can be used to obtain information about user-activity on a site using cookies.

Download

You can download and install the Session Tracker module along with the source code from here. A tiny disclaimer here, this is not an official Microsoft extension (hence not supported by Microsoft), but a personal contribution to the download centre. You can direct all queries and improvements to the module directly to me, and i will try my best to address them.

Features

The Session Tracker module comprises of a sessionTracking.xml and a SessionTracking.dll and has the following key features

The module when enabled, will attach a Set-Cookie header in the server response which will enable subsequent requests from the client to be tracked using Cookies. The module can also send a Cache-Control header in the response.

The schema lets you disable/enable the SessionTracking module.

The schema helps you dictate the name of the cookie and the cookie style information (whether you want to send Set-Cookie or a Set-Cookie2 header in the response). You can also set certain other attributes of the cookie like Max-Age, Path, Version, Secure, etc. as described in RFCs 2109 and 2965.

The schema also enables you to send Cache-Control headers in the response. This is outlined in RFC 2616.

Installation

You should be able to install the Session Tracker module on an IIS 7.0 machine, by following these simple steps.
Install the SessionTracker.EXE installer onto a folder on your IIS 7.0 machine. The installer would copy the source code, Visual Studio project files, binaries (x86 and x64) and schema required for the working of the sessionTracker module.

Run the installScript.js from this folder on an administrator command prompt. The script would copy SessionTracking.dll to %windir%\system32\inetsrv and to the %syswow64%\system32\inetsrv on an x64 machine. The script also copies the sessionTracking.xml schema file to %windir%\system32\inetsrv\config\schema.

Install the SessionTrackingModule by using the following appcmd command
appcmd.exe install module /name:SessionTrackingModule /image:%windir%\system32\inetsrv\SessionTracking.dll
Make the following changes to \inetsrv\config\applicationHost.config file on your server.
Declare the sessionTracking section in the <system.webServer> sectionGroup for it to be recognized by appcmd.exe
              <configSections>
                <sectionGroup name="system.webServer">
                       <section name="sessionTracking" allowDefinition="AppHostOnly" overrideModeDefault="Allow" />
                </sectionGroup>
              </configSections> 
Now, you can enable the sessionTracking section at the server level using the following appcmd command
                          appcmd.exe set config /section:sessionTracking /enabled:true

    6.   You can list the sessionTracking section, containing default values with the following appcmd command.

                          appcmd.exe list config /section:sessionTracking /config:*

Implementation

The Session Tracker module kicks in during the RQ_BEGIN_REQUEST state of the request pipeline.

If the module sees a Cookie header in the request already, it will be interpreted as a session already initiated by the server. In that case, the module will return control to the request pipeline by returning RQ_NOTIFICATION_CONTINUE. That way, default site functionality will not be interrupted.

If the module does not see a Cookie header in the request, then this will be treated as a new request. The module, then reads the config data, and builds a Set-Cookie header using the information defined by the user in the config. It will then obtain the response from the server and adds the Set-Cookie header to the response.

The module also takes care of adding a Cache-Control header to the response. After adding this header, the module prevents any further processing of the request by returning an RQ_NOTIFICATION_FINISH_REQUEST.

Working

To see the working of the session tracker module, you can follow the steps below

Enable Failed Request Tracing on your website for status codes 200-500.

Delete all previous cookies from IE and then browse once to the site.

Open the trace log file (default location %systemdriv%\inetpub\logs\FailedReqLogFiles). Your request and response headers will look like this.





          The Set-Cookie header in the response is generated and added to the response by the Session Tracker module.

Refresh the site from the second step again with IE.

You will find another trace log file generated at the same location. Your request header for the second request will now look like this

Thereafter all subsequent requests in the same session would have this Cookie header set.

Usage

You can use the Session Tracker module along with LogParser 2.2 to parse the IIS 7.0 logs and generate a log of user-activity on the website.

As a first step, enable logging on your website and select the cs(Cookie) w3c logging field. For more information, you can refer this link.

Now, you can execute the following LogParser query on the log file generated for the site (default location is %systemdrive%\inetpub\logs\LogFiles).to obtain a log of user-activity for a particular session. The highlighted item is the name=value field from the cookie generated.

     LogParser "SELECT cs-uri-stem from u_ex090109.log where cs(Cookie)='IIS7SessionTracking=18302628887781179643'"

     Output:

To obtain a list of all the Cookies given out by the server, you can execute the following LogParser command.

LogParser "SELECT cs(Cookie),count(*) from u_ex090109.log GROUP BY cs(Cookie)"

Acknowledgements

I would like to thank Kanwal for his invaluable feedback and initial research and Cip for the initial implementation of the Session Tracker module.

References

http://learn.iis.net/page.aspx/169/develop-a-native-cc-module-for-iis-7/

http://blogs.iis.net/ksingla/archive/2008/12/21/using-imetadatainfo-getmodulecontextcontainer-to-store-configuration-data.aspx

http://www.ietf.org/rfc/rfc2109.txt
http://www.ietf.org/rfc/rfc2965.txt
http://www.ietf.org/rfc/rfc2616.txt

Getting started with writing a FastCGI Client application (FastCGI Test Client)

yaminij — Thu, 08 Jan 2009 02:05:00 GMT

I worked on the FastCGI for IIS 6.0 RTM release a while ago and during that time, I worked on developing a FastCGI Client application, in order to test FastCGI at a protocol level. I just decided to blog about it, just in case any of you are interested in getting started with writing a FastCGI client application from scratch.

You can download the sample client application along with the source code from here. This application can work both over TCP and Named Pipes.

The FastCGI Client application is a generic application that will be used to communicate with the Web Server (FastCGI handler) through FastCGI protocol either over Named Pipes or TCP. The FastCGI test client communicates in the form of messages with the FastCGI Server. All these messages are in the form of STDIN, STDOUT and STDERR. The Web Server (FastCGI Handler) creates a Named Pipe or a TCP stream for communication and duplicates these handles onto the stdout, stdin and stderr (parent processes can override the stdin, stdout and stderr of child). By this, the application just has to write it’s protocol messages to stdin, stdout and stderr and the details of the TCP/Named Pipe communication is abstracted out.

As a first step, you can determine if the application was invoked using CGI or FastCGI by calling getpeername on the STD_INPUT_HANDLE. You should get a socket error if the client was invoked using a FastCGI application. Depending on whether your server uses TCP or Named Pipes, your WSAGetLastError() could return WASENOTCONN or WSAENOTSOCK respectively.

bool IsApplicationInvokedUsingFastCGI( HANDLE s )
{
        // Determine if this application was invoked using CGI or FastCGI
        struct sockaddr nameOfConnectedSocket;
        int nameLenOfConnectedSocket;
        HRESULT hr = S_OK;
        int errs; 

        errs = getpeername( (SOCKET)s, &nameOfConnectedSocket, &nameLenOfConnectedSocket );        
        if ( errs == SOCKET_ERROR )
        {
            hr = HRESULT_FROM_WIN32( WSAGetLastError() );
            if(  hr == HRESULT_FROM_WIN32( WSAENOTCONN ) )
            {
                    //LogMessage( TRACE_MESSAGE, "Application was invoked using FastCGI over TCP, got a WSAENOTCONN on a call to getpeername()" );                    
                    return TRUE;
            }
            else            
            if( hr == HRESULT_FROM_WIN32( WSAENOTSOCK ) ) 
            {                    
                    //LogMessage( TRACE_MESSAGE, "Application was invoked using FastCGI over Named Pipe, got a WSAENOTSOCK on a call to getpeername()" );                    
                    return TRUE;
            }            
            else            
            {                                        
                    return FALSE;            
            }
        }        
        else
        {
            // Quit, this app is not compatible with FastCGI
            //LogMessage( TRACE_MESSAGE, "Application was invoked using CGI, getpeername() successful" );
            return FALSE;
        }        
}

Next step to writing a client is to try and determine if the communication with the Web Server should happen over Named Pipes or TCP. Do an accept() socket call on the STDIN and if it succeeds, use TCP, else use Named Pipes.

bool IsNamedPipeOrSocket( HANDLE hStdin, FASTCGI_PROTOCOL * useNamedPipeOrSocket )
{
        HRESULT hr = S_OK; 

        try
        {
            acceptSocket = accept( (SOCKET)hStdin, NULL, NULL ); 

            if( acceptSocket == INVALID_SOCKET )
            {
                (*useNamedPipeOrSocket) = FcgiConfigProtocolNamedPipe;                
            }
            else
            {
                (*useNamedPipeOrSocket) = FcgiConfigProtocolTcp;
            }            
        }
        catch(...)
        {
            //LogMessage( TRACE_EXCEPTION, "Exception is IsNamedPipeOrSocket() function" );
            return FALSE;
        }
        return TRUE;
}

Then Initialize the transport connection and receive and send messages from and to the FastCGI Server respectively. For more information on this exchange please refer the FastCGI protocol specification.

// Initialize the transport connection based on whether the Server is using Named Pipes or TCP.
if( namePipeOrSocket == FcgiConfigProtocolNamedPipe )
{
        pTransport = new TRANSPORT_NAMEDPIPE();
}
else
{
        pTransport = new TRANSPORT_TCP();
}

class TRANSPORT
{
    public: 

        TRANSPORT()
        {}
        ~TRANSPORT()
        {} 

        HRESULT Send( PBYTE pBuffer, DWORD dwSize)
        {
            return SendReceive( TRUE, pBuffer, dwSize );
        }
        HRESULT Receive( PBYTE pBuffer, DWORD dwSize)
        {
            return SendReceive( FALSE, pBuffer, dwSize );
        } 

    protected: 

        virtual HRESULT SendReceive( bool fSend, PBYTE pBuffer, DWORD dwSize ) = 0;
};

class TRANSPORT_NAMEDPIPE : public TRANSPORT
{

class TRANSPORT_TCP : public TRANSPORT
{

class TRANSPORT_NAMEDPIPE : public TRANSPORT
{
    public: 

        TRANSPORT_NAMEDPIPE()
        {}
        ~TRANSPORT_NAMEDPIPE()
        {}
    protected:            

        HRESULT SendReceive( bool fSend, PBYTE pBuffer, DWORD dwSize )
        {
            BOOL fRet  = FALSE;
            DWORD dwLastError = 0;
            DWORD nNumberOfBytesRead = 0; 

            if( fSend == TRUE )
            {        
                fRet = WriteFile( hStdin, pBuffer, dwSize, &nNumberOfBytesRead, NULL );
            }
            else
            {
                fRet = ReadFile( hStdin, pBuffer, dwSize, &nNumberOfBytesRead, NULL );
            } 

            if(!fRet)
            {
                dwLastError = GetLastError();
            } 

            return HRESULT_FROM_WIN32( dwLastError );
        }
}; 

class TRANSPORT_TCP : public TRANSPORT
{
    public: 

        TRANSPORT_TCP()
        {}
        ~TRANSPORT_TCP()
        {} 

    protected: 

        HRESULT SendReceive( bool fSend, PBYTE pBuffer, DWORD dwSize )
        {
            int iRet = 0;
            WSABUF winsockBuffer;
            DWORD   dwBytesTransferred  = 0;
            DWORD   dwFlags             = 0;
            DWORD   dwLastError            = 0; 

            winsockBuffer.len = dwSize;
            winsockBuffer.buf = (char *)pBuffer; 

            if( fSend == TRUE )
            {
                iRet = WSASend( acceptSocket, &winsockBuffer, 1, &dwBytesTransferred, 0, NULL, NULL ); 
            }
            else
            {
                iRet = WSARecv( acceptSocket, &winsockBuffer, 1, &dwBytesTransferred, &dwFlags, NULL, NULL );
            } 

            if( SOCKET_ERROR == iRet )
            {
                dwLastError = WSAGetLastError();
            } 

            return HRESULT_FROM_WIN32( dwLastError );
        }
};

A while ago, Rick who was the developer of the FastCGI core module, published a fake fastcgi server that works only over Named Pipes. To quickly see the working of this client application, you can run it with the fake server as below. The highlighted messages are returned by the client application TestClient.exe.

D:\fake>fakefcgi.exe d:\php\hello.php TestClient.exe
Fake FastCGI web server
FCGI_PARAMS sent
FCGI_STDIN sent
Launching receive loop
FCGI_STDOUT: FCGIClient : Obtained FCGI_BEGIN_REQUEST message from Server
FCGI_STDOUT: FCGIClient : Obtained FCGI_PARAMS from Server
FCGI_STDOUT: FCGIClient : Obtained FCGI_STDIN from Server
FCGI_STDOUT: FCGIClient : Sending FCGI_END_REQUEST to Server
FCGI_END_REQUEST received
killing app
FastCGI process exited with 0