Archives

Archives / 2008 / December

  • Using IMetadataInfo::GetModuleContextContainer to store configuration data

    No Comments

    If you write an IIS7 module, you would typically want to control its behavior based on some configuration data. IIS7 makes it really easy for developers to extend configuration schema so that their customers can put configuration data for their modules with other IIS configuration in applicationHost.config and web.config. Native module developers can then use AhAdmin APIs to read this configuration data. Reading configuration data for each request can be expensive. Developers would typically think of improving the performance by reading the configuration data once and then keeping the data in memory which can be used for other requests. To do this right, you need to worry about following things.

    • Keep unique data only for the paths where configuration changes and not for all possible configuration paths.
    • Detect configuration changes so that module always behave as per the latest configuration.
    • Only delete the configuration data of paths which are affected by the change and not throw everything.
    • Make sure this configuration store is accessed in thread safe manner.
    Instead of implementing this from scratch, you can use IMetadata interface available in httpserv.h. Call IHttpContext::GetMetadata() to get IMetadata object which is different for each unique configuration path and then use the IMetadataInfo::GetModuleContextContainer()->SetModuleContext() to store any data you like for your module. Configuration data is a perfect example of kind of data you would like to store for a unique configuration path. Stored data can be retrieved using IMetadataInfo::GetModuleContextContainer()->GetModuleContext(). In addition to making sure that a unique metadata object is available only for paths where configuration changes, IIS will also take care of deleting proper stored contexts when a change notification arrives. Here is how doing this will look like in code.

    //
    // Globals
    //
    HTTP_MODULE_ID g_pModuleContext = NULL;
    IHttpServer *  g_pGlobalInfo    = NULL;

    HRESULT
    WINAPI
    RegisterModule(
        DWORD                          dwServerVersion,
        IHttpModuleRegistrationInfo *  pModuleInfo,
        IHttpServer *                  pGlobalInfo
    )
    {
        ...

        g_pGlobalInfo    = pGlobalInfo;
        g_pModuleContext = pModuleInfo->GetId( );

        ...
    }

    class MODULE_CONFIG : public IHttpStoredContext
    {
    public:

        //
        // Always call this method to get configuration data
        //
            static
        HRESULT
        GetModuleConfig(
            IHttpContext *   pContext,
            MODULE_CONFIG ** ppModuleConfig
        );

        HRESULT
        Initialize(
            IHttpContext * pContext
        );

        // virtual
        VOID
        CleanupStoredContext(
            VOID
        )
        {
            delete this;
        }

        //
        // Stored Configuration Data
        //
    };

    //static
    HRESULT
    MODULE_CONFIG::GetModuleConfig(
        IHttpContext *   pContext,
        MODULE_CONFIG ** ppModuleConfig
    )
    {
        HRESULT                       hr                 = S_OK;
        MODULE_CONFIG *               pModuleConfig      = NULL;
        IHttpModuleContextContainer * pMetadataContainer = NULL;

        pMetadataContainer = pContext->GetMetadata()->GetModuleContextContainer();
        pModuleConfig = (MODULE_CONFIG *)pMetadataContainer->GetModuleContext( g_pModuleContext );

        if ( pModuleConfig != NULL )
        {
            //
            // We found stored data for this module for the metadata
            // object which is different for unique configuration path
            //
            *ppModuleConfig = pModuleConfig;
            return S_OK;
        }

        //
        // If we reach here, that means this is first request or first
        // request after a configuration change IIS core will throw stored context
        // if a change notification arrives for this metadata path
        //
        pModuleConfig = new MODULE_CONFIG();
        if ( pModuleConfig == NULL )
        {
            return E_OUTOFMEMORY;
        }

        //
        // Read module configuration data and store in MODULE_CONFIG
        //
        hr = pModuleConfig->Initialize( pContext );
        if ( FAILED( hr ) )
        {
            pModuleConfig->CleanupStoredContext();
            pModuleConfig = NULL;

            return hr;
        }

        //
        // Store MODULE_CONFIG data as metadata stored context
        //
        hr = pMetadataContainer->SetModuleContext( pModuleConfig,
                                                   g_pModuleContext );
        if ( FAILED( hr ) )
        {
            pModuleConfig->CleanupStoredContext();
            pModuleConfig = NULL;

            //
            // It is possible that some other thread stored context before this thread
            // could do. Check returned hr and return context stored by other thread
            //
            if ( hr == HRESULT_FROM_WIN32( ERROR_ALREADY_ASSIGNED ) )
            {
                *ppModuleConfig = (MODULE_CONFIG *)pMetadataContainer->GetModuleContext( g_pModuleContext );
                return S_OK;
            }
        }

        *ppModuleConfig = pModuleConfig;
        return hr;
    }

    HRESULT
    MODULE_CONFIG::Initialize(
        IHttpContext * pContext
    )
    {
        HRESULT                hr               = S_OK;
        IAppHostAdminManager * pAdminManager    = NULL;
        IAppHostElement *      pAppHostElement  = NULL;
        BSTR                   bstrSectionName  = NULL;
        BSTR                   bstrConfigPath   = NULL;
        ...

        pAdminManager = g_pGlobalInfo->GetAdminManager();
        ...

        //
        // Read configuration data at metapath of IMetadataInfo object
        //
        bstrConfigPath = SysAllocString( pContext->GetMetadata()->GetMetaPath() );
        ...

        hr = pAdminManager->GetAdminSection( bstrSectionName,
                                             bstrConfigPath,
                                             &pAppHostElement);
        ...
    }

    Hope this helps.
    Kanwal

    Read more...

  • Generating configuration to allow/deny access to countries

    No Comments

    There have been few requests on forums where people wanted to control access to sites based on country from where request originated. We recommended people to use IP restriction module functionality which required people to add IP address ranges of the countries they want to grant or deny access in ipSecurity section. This is easier said than done. There are a number of IP-to-country mapping lists available for free and updated frequently. These lists are usually in CSV format and identify countries (and sometimes even regions in the country) to which a particular IP-range is assigned. One such list can be downloaded from here. Entries in the CSV file go from 0 to max 32-bit unsigned integer. As the IP ranges assigned to a country are not contiguous, there are many entries (sometimes thousands) for one country. IIS7 IPRestriction module let you specify an IP-range using start-IP address and subnet mask. To move a single entry from CSV to IIS configuration you are required to create start IP address from a 32-bit integer and also create a subnet mask from IP-range both of which are not trivial. Also because most countries have hundreds of IP ranges assigned to them, going through CSV picking up these entries and then calculating start IP address and subnet mask manually is extremely difficult. Few days ago I wrote a script which does this for you. You can download the IP-to-country mapping list from here, unzip it (to say ip-to-country.csv) and then use the attached script (save ipres.js.txt as ipres.js).

    To see list of countries for which IP ranges are given in CSV, use “cscript.exe //nologo ipres.js /f ip-to-country.csv /l”
    To generate ipSecurity configuration to block access to a country, use “cscript.exe //nologo ipres.js /f ip-to-country.csv /d FewCharsToFilterCountry”
    To generate ipSecurity configuration to grant access to a country, use “cscript.exe //nologo ipres.js /f ip-to-country.csv /a FewCharsToFilterCountry”
    To find a particular IP address in this list, use "cscript.exe //nologo ipres.js /f ip-to-country.csv /g ip-address"

    You can specify more than one country separated by commas to filter on. Also you can use ‘*’, ‘?’ wildcard characters in country name filter. Script will dump the configuration on the console which you can paste in ipSecurity section. Feel free to change the script to make it emit adsutil.vbs calls to add entries to IIS6 metabase.

    In IIS7, ipSecurity section is locked by default. If you want to block access to a site, unlock ipSecurity section and add configuration for the site only. If you are adding the entries in web.config, you can use configSource option to keep the ipSecurity configuration in a separate file. Keep in mind that changes to configSource target file are not automatically picked up unless web.config file containing configSource attribute is changed. Also if you run into web.config file size limit, you can increase it by changing MaxWebConfigFileSizeInKB as specified in this blog.

    Hope this helps.
    Kanwal

    Read more...