The <InProcess> element contains settings governing the portion of the SP that runs inside the web server. It also includes content specific to particular web servers that supply an inadequate native configuration mechanism. It is required for Microsoft IIS usage, and is optional otherwise.
Attributes
| Name | Type | Default | Description |
|---|---|---|---|
logger | local pathname | native.logger | This attribute points to a configuration file that defines in-process logging behavior, defaulting to a local syslog or Event Log. If set, this overrides the logger property in the <SPConfig> parent element, but if omitted (defaulted), the parent property will take precedence. |
catchAll | boolean | false | If true, "global" exception handlers are used to trap crashes and other "uncontrolled" exceptions. This attempts to keep the web server process running if at all possible, but makes diagnosing bugs difficult, and can lead to unstable runtime behavior. Generally should be left off. |
unsetHeaderValue | string | (the empty string) | When HTTP headers are used to supply exported attributes to applications (and you shouldn't), this value will be placed into headers corresponding to attributes that are not supplied, or that have no values. Defaults to an empty string (to represent a "null" value), but may be set to a an actual value, such as "UNKNOWN". |
checkSpoofing | boolean | true | If true, the SP will examine incoming headers supplied by the client and will fail the request if any of them match header names "controlled" by the SP. Do NOT disable this setting unless you have a strong reason to do so. This isn't the sum total of the steps the SP takes to make header usage possible, but it is a useful second line of defense. |
spoofKey | string | Optional "secret" value used to prevent false alarms from the |
Preventing Header Spoofing
When using Apache and IIS, you should strongly consider porting applications to rely on system variables in place of request headers.
If this is not possible, the checkSpoofing feature should be enabled. Server-side redirects, aliasing, and modules like mod_rewrite tend to cause false alarms because the SP detects headers that it itself has already created. To prevent this, the spoofKey setting enables a special header as a way of detecting whether the headers being examined came from the SP or the client. The idea is to make it difficult for a client to guess this value and spoof the key, which then bypasses the spoof detection code.
On the IIS platform, a random key is automatically generated to ensure the detection feature works safely. On other platforms, you would need to establish the spoofKey setting yourself. It should contain a suitably long, random value, and you MUST prevent the client from accessing any server-side scripts that might expose the key value through a dump of arbitrary request headers.
Child Elements
| Element | Cardinalty | Description |
|---|---|---|
<Extensions> | 0 or 1 | Specifies any in-process extension libraries. |
<ISAPI> | 0 or 1 | Controls the Integration with the Microsoft IIS web server, ignored by other modules. |
Example
<InProcess>
<ISAPI>
<Site id="1" name="sp.example.org" />
</ISAPI>
</InProcess>