Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

The <Path> element is used to apply content rules to requests containing a specific path segment.

Path matching can be nested, and embedding multiple path segments in a single element is also allowed to simplify authoring rules. However, segments between matching portions cannot be skipped, except by using the <PathRegex> element instead.

Path matching is also greedy. As much of the request's path as possible is consumed during each comparison, and only the remaining portion is used in any subequent nested comparison.

Finally, do not attempt to use a <Path> element with only a "/" character to indicate the root of a virtual host. It will be ignored, and your log will contain a warning. Put any settings that apply to a virtual host in the parent <Host> element.

Attributes

Content Specifiers

Names

Type

Description

name string

Required attribute, specifies a path segment to match against. Lower case must be used, and case sensitive matching is not permitted. Multiple segments can be included by using slashes to separate them.

Content Settings

XML attributes corresponding to request mapper properties are used.

Child Elements

Access Control 

One of the following child elements can be used to attach an access control policy to matching requests:

  • <htaccess>

    • Enables native Apache .htaccess support during Apache's authorization phase. This is automatic and implicitly plugged in for the Native RequestMapper, but can be enabled by hand if the XML RequestMapper is used. Note that this will fail for non-Apache servers.

  • <AccessControl>

    • Attaches an access control policy using the XML-based plugin provided with the SP. This is a short-hand for embedding the policy in the element above, if you want the policy inside the RequestMapper's configuration file anyway.

If no element is included (or inherited or implicitly enabled), any access control is left to the resource itself and the SP simply passes its session information along.

If an error occurs when processing this element, a dummy policy to deny access is installed to prevent accidental exposure.

Nested Content Specifiers

Unable to render {include} The included page could not be found.

Example

<RequestMapper type="Native">
    <RequestMap applicationId="default">
        <Host name="sp.example.org">
            <!-- Example of a single nested path segment -->
            <Path name="secure">
                    <!-- Example of a multiple path segments separated by slashes -->
                    <Path name="/create/new/class" authType="shibboleth" requireSession="true">
                            <AccessControl><NOT><Rule require="affiliation">student</Rule></NOT></AccessControl>
                    </Path>
            </Path>
        </Host>
    </RequestMap>
</RequestMapper>
  • No labels