Date: Fri, 29 Mar 2024 14:36:34 +0000 (UTC) Message-ID: <359465962.7.1711722994691@d3dccb36a06f> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6_177387959.1711722994691" ------=_Part_6_177387959.1711722994691 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The <Path>
element is used to apply content r=
ules to requests containing a specific path segment.
Path matching can be nested, and embedding multiple path segments in a s=
ingle element is also allowed to simplify authoring rules. However, segment=
s between matching portions cannot be skipped, except by using the <PathRegex>
element ins=
tead.
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 hos=
t. It will be ignored, and your log will contain a warning. Put any setting=
s that apply to a virtual host in the parent
<Host>
elem=
ent.
name
(string)=20
XML attributes corresponding to request mapper properties are used.
=20 <RequestMapper type=3D"Native"> <RequestMap applicationId=3D"default"> <Host name=3D"sp.example.org"> <!-- Example of a single nested path segment --> <Path name=3D"secure"> <!-- Example of a multiple path segments separat= ed by slashes --> <Path name=3D"/create/new/class" authType=3D"shi= bboleth" requireSession=3D"true"> <AccessControl><NOT><Rule re= quire=3D"affiliation">student</Rule></NOT></AccessControl= > </Path> </Path> </Host> </RequestMap> </RequestMapper>
One of the following elements can be used to attach an access control po= licy to the resource. This is a violation of the axiom that the SP doesn't = do access control, but it's really just a call-out that has some predefined= plugins you can use as examples to create more.
<htaccess>
.htaccess
support during the authorization =
phase. This is automatic and implicit for the "Native" request mapper, but can be enabled by hand if the "XML" request mapper is used. Note that this will =
fail for non-Apache servers.<AccessControlProvider&g=
t;
<AccessControl>
If no element is included (or inherited or implicitly enabled), any acce= ss control is left to the resource.
If an error occurs when processing this element, a dummy policy to deny = access is installed to prevent accidental exposure.
Zero or more of these "overrides" to match specific content deeper insid= e the matched path can be included.
<Path>
<PathRegex>
<Query>
Matching is done as follows:
1. First, by examining <Path>
elements in order.
2. Then, by checking any <Pat=
hRegex>
elements in order against the part of the path that w=
as not matched in the first step.
3. Finally, by examining any <Que=
ry>
elements in order.
Once a match on the name
attribute is found, the process st=
eps "into" that element and no other siblings will be applied. Thus, siblin=
gs cannot overlap.
For more details on how the request mapping process works, see the request mapper HOWTO.