Various custom configuration elements support a common content model used to supply JSR-223 scripts inside other object configurations. Where applicable, the specific configuration elements that share this content model will link to this page. These include the following documentation pages:
...
| Excerpt |
|---|
AttributesAn element of type ScriptType has the following XML attributes: Name | Type | Use | Default | Description |
|---|
language | string | optional | "javascript" | Defines the JSR-223 language to use. The default is ECMAScript using either the Rhino (Java 7) or Nashorn (Java 8) engines. | customObjectRef 3.2
| string | optional |
| The ID of a Spring bean defined elsewhere in the configuration. |
If the customObjectRef attribute is present, the result of the referenced Spring bean is made available to the script in a variable named custom. This is in addition to the normal script context discussed below. Child ElementsAn element of type ScriptType has the following child elements: | Name | Cardinality | Description |
|---|
<Script> |
Exactly One
| An inline script | <ScriptFile> | Path to a local file or classpath resource containing the script |
The script may be stored in a local file (with <ScriptFile>) or written inline (with <Script>). An inline script should be wrapped with a CDATA section to prevent interpretation of any special XML characters that may be included in the script. | Tip |
|---|
| title | Always wrap inline scripts with a CDATA section |
|---|
| Always wrap inline scripts with a CDATA section, even if the script contains no special XML characters. This will future-proof your script. |
|
...
| Note |
|---|
| title | Using the JSLint tool |
|---|
|
The JSLint tool cannot tell that the JavaScript is being run within the environment of the IdP, with the implied inputs and outputs that that infers. This manifests itself in two ways: - It dpes JSLint does not like the
input object and other customobjects that seem to magically appear from nowhere. From a Shibboleth perspective, this is a feature, not a bug. You can safely ignore this warning issued by the JSLint tool. Equally it does not like the "last value is the implied return" paradigm. Should this grate you can fool JSLint by using a closure as the last line, for instance replacing | Code Block |
|---|
var retVal;
retVal = false;
//
// arbitrary code to set up retVal, consulting input and customref
//
retVal; |
with | Code Block |
|---|
var retVal;
retVal = false;
//
// arbitrary code to set up retVal, consulting input and customref
//
(function (val) {
return val;
}(retVal)); |
Only you can decide whether this will help maintainabilty. For clarity and didactic purpose the examples omit this paradigm.
|
...