Since pipeline execution can be triggered from external sources via an URL, special care is necessary to secure pipelines, making sure that a pipeline responds only to requests from authorized clients.
The configuration parameters for a start node include the call mode parameter. The call mode determines whether a pipeline can be triggered from an external source using HTTP requests, or from an internal source only using call or jump nodes. The call mode parameter for start nodes can take the following values:
for access from an external source such as the storefront, using (for example) HTTP requests.
Example for a public call:
Such a public request allows only to call a
public start node.
for access via remote include calls (Web Adapter includes,
Example for a include call:
An included request allows to call a
public or an
include start node.
for access from an internal source such as another pipeline, using call or jump nodes.
Example for a internal call:
<ispipeline pipeline=”ProcessPagelet-TemplateCallback” params=”#ParamMap#”>
An internal request allows to call a
include or a
private start node.
For example, many viewing pipelines are triggered by external sources via HTTP requests, hence need to have a public start node. On the other hand, processing pipelines are typically called from viewing pipelines. Therefore, processing pipelines typically have private start nodes.
Prefix pipelines are generic pipelines which perform certain checks before the pipeline that has actually been requested is executed. Prefix pipelines therefore provide a powerful mechanism to prevent unauthorized access to public pipelines.
Intershop 7 supports so-called site prefix pipelines. The site preference value
SitePrefixPipeline specifies the name of a pipeline which is automatically called before any public pipeline in the site is executed. The default value is set to the
CorePrefix pipeline. See the figure below for details on this pipeline.
The pipelet processor checks the SitePrefixPipeline preference value only once, the first time a pipeline in the site is executed. The
SitePrefixPipeline preference value is re-read only if the pipelines of the site or all pipelines in the system are reloaded.
If a pipeline is executed and the site's
SitePrefixPipeline preference value contains a prefix pipeline name, the prefix pipeline is looked up in the normal manner and is then executed. This also means that a prefix pipeline can be overloaded in the usual way.
Different versions of the prefix pipeline can be defined using the start nodes:
These different versions are executed depending on the type of the pipeline (
Backoffice) triggering the prefix pipeline.
For example, if the original pipeline being executed is of type
Process, a start node process is searched for in the prefix pipeline. If the system cannot find one, the pipelet processor looks for a default start node named
Start. The name of the originally called pipeline and the start node name are put into the prefix pipeline dictionary using the
The pipeline type is stored in the pipeline's XML descriptor file. By default, the pipeline types are stored in lower case letters (e.g., <type>process</type>. Since the pipeline lookup mechanism is case sensitive, the respective prefix pipeline start nodes must be lower case as well.
The originally called pipeline is not executed after the site prefix pipeline if the following happens:
If the site prefix pipeline ends with a named end node, the originally called public pipeline is executed. The
SitePrefixEndNodeName value of the site prefix pipeline is passed to the dictionary. The values of the site prefix pipeline dictionary are available to the original pipeline as well.
The CorePrefix pipeline is a prefix pipeline which is provided as a default. The pipeline checks if a user has the required permission to run a called pipeline. This is, basically, a two-step process:
The permissions themselves are configured in the pipelines-acl.properties file, located in the pipeline directory of every cartridge, and pre-loaded during the pipeline cache initialization.
If a pipeline requires a permission of the requester to execute the pipeline in general, or a specific start node of this pipeline, the pipeline's cartridge contains a pipelines-acl.properties file. The pipelines-acl.properties file includes the access control list (ACL) for every pipeline of the cartridge or site whose access should be restricted. These access control lists are loaded into the pipeline cache upon server startup or pipeline reload.
The pipelines-acl.properties located in
As pipelines are always executed within a site context, the common pipeline lookup and overload mechanism must apply to the ACL lookup as well. The following steps are performed:
the cartridges that are currently loaded in the given site are determined
The order within the list of cartridges bound to a site is relevant. The system sequentially searches for cartridge resources in a top-down manner, starting with the first cartridge in the list.
The access control list lookup also considers cartridges and sites that do not define any pipelines. In this case, the cartridge's or site's pipeline directory only contains the file pipelines-acl.properties. This allows developers to overload the ACLs of pipelines by their project specific cartridges or sites.
The pipelines-acl.properties files must match a specific syntax. As all properties files, they are made of key-value pairs. The pipelines-acl.properties files define the required permission for each pipeline-start node combination.
The following lines illustrate the ACL syntax:
<-- permission list for a given context for a specific start node of a pipeline --> <PipelineName>-<StartNodeName>=<Context>:<PermissionID> <-- permission list for a given context for an entire pipeline --> <PipelineName>=<Context>:<PermissionID>
The key is
PipelineName-StartNodeName. The value is a semicolon separated list of
Context:PermissionID pairs. In addition, you can define a default access control list for each pipeline without a start node, or an empty access control list for a pipeline.
... ViewCatalog=Channel:NONE;Organization:SLD_MANAGE_CATALOGS ViewCatalog-Dispatch=Channel:NONE;Organization:NONE ViewCatalog-Edit=Channel:NONE;Organization:SLD_VIEW_CATALOGS ... ViewCatalogCategoryEditing=Enterprise:SLD_MANAGE_CATALOGS
The entries for
ViewCatalog are treated as independent entries and are not merged during the cache initialization.
A call for
Channel denotes PrimeTech-Specials and the context
Organization denotes PrimeTech), a call for
ViewCatalog-Dispatch returns an empty list.
A call for
Channel:NONE;Organization:SLD_MANAGE_CATALOGS which is the pipelines fallback if a specific start node of the pipeline is not listed in the
Enterprise of the pipeline
ViewCatalogCategoryEditing means both, the
Organization context and the
Permissions are always checked against an
AuthorizationObject, i.e., a context, and that one or more permissions need to be checked before a pipeline is executed upon a user's request. This behavior is represented in the
Context defines the authorization object used to check the permission specified in
For example, the ACL:
means that if a user wants to start the pipeline
ViewCatalog via the start node
Edit, the permission
SLD_VIEW_CATALOGS must be checked against the authorization object
Organization. The number of
Context:PermissionID pairs per access control list is not limited, but a
Context:PermissionID pair should not appear more than one time in an access control list.
See the Intershop Studio User Guide- Creating Pipelines | Manage Pipeline Access Control for detailed information on how to manage the permissions of the access control list. The Intershop Studio User Guide is available as Online Help of Intershop Studio.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.