Web Filter Basics

When a Web filter is loaded, the Forefront TMG Web proxy passes pointers to one or two HTTP_FILTER_VERSION structures to the Web filter, depending on which entry-point functions are implemented by the Web filter. The Web filter uses members of these structure to pass information back to the Web proxy. This information includes the version number of the Web filter API used by the Web filter and a bitmask that specifies the types of Web proxy events for which the filter should be notified. Each time one of those events occurs, an event notification is sent to every Web filter that has specified interest in that event.

When designing a Web filter, consider what events you want the filter to react to, and decide what processing the filter will perform when each event occurs. In addition to these basic design considerations, you must ensure that the Web filter will be properly installed by adding it to the collection of Web filters (the FPCWebFilters collection) so that it is loaded by the Web proxy.

When you add a Web filter to this collection, you must set its priority, which is stored in the Priority property of the FPCWebFilter object created. Web filters that alter the data being transferred, such as encrypting or decrypting filters, should be assigned a higher priority than other Web filters during setup. For more information, see Web Filter Administration.

Web filters should never trust an upstream proxy server and forward user credentials to it.

If a Web filter modifies the content of the data stream, it might inadvertently pass modified versions of signatures in the request or response header that it is configured to look for.

If a Web filter creates a new authentication scheme when it is registered with Forefront TMG, Forefront TMG Management must be restarted before it will display the new authentication scheme.

 

 

Build date: 7/12/2010