4.8 Content Server Communication Customization

The following sections provide information on how to customize access to and communication with Content Server. It includes the following:

• "Login/Logout Customization"

• "Browser URL Customization"

• "Extended User Attributes"

• "Filter Data Input"

4.8.1 Login/Logout Customization

The ExtranetLook component can be used to customize user access by suppressing the interface for users who are not authenticated by Oracle WebLogic Server through error and challenge pages issued by the Web server. See Oracle Fusion Middleware Developer's Guide for Content Server for details about changing the interface.

The ExtranetLook component is installed (disabled) by default with Content Server. To use the component you must enable it with the Component Manager.

4.8.2 Browser URL Customization

The BrowserUrlPath component provides support for determining URL paths used in certain configurations of Content Server and Web servers. This component is installed (disabled) by default with Content Server. To use this component you must enable it with the Advanced Component Manager.

This component is valid for Oracle Universal Content Management Content Server instances deployed on Oracle WebLogic Server and located behind load balancers.

The following topics are discussed in this section:

• "About BrowserUrlPath Customization"

• "Affected Idoc Script Variables and Functions"

• "Determining the URL Path"

• "Changing Absolute Full Path Computation"

• "Changing Administration Path Computation"

4.8.2.1 About BrowserUrlPath Customization

The BrowserUrlPath component overrides certain Idoc Script variables and functions, adds computation to certain variables, and provides additional configuration entries for determining URL paths. The BrowserUrlPath component is only supported with Trays and Top Menu layouts for the Content Server user interface.

• You can configure a system with different Web server front ends. One front end can use HTTP and the other can use HTTPS so that the content server can be accessed simultaneously by Web sites using HTTP and HTTPS. You then must apply the BrowserUrlPath component to enable the content server to handle both types of access.

• If you are using a load balancer that forwards itself as the HTTP host header, then you must apply the BrowserUrlPath component.

BrowserUrlPath configuration variables are located in the UCM_ORACLE_HOME/ucm/idc/components/ BrowserUrlPath/config.cfg file.

Caution: The BrowserUrlPath component requires extensive configuration using the variables. You may want to back up your configuration before modifying variables

In typical scenarios, the web server will forward to the Content Server two critical pieces of information:

• HTTP_HOST: The host header that the browser sends, identifying the host as it appears to the user in their browser address bar.

• SERVER_PORT: The port the browser uses in connecting to the Content Server.

The browser-based full address is used for two critical pieces of functionality:

1. Automatic creation of URLs in the left-hand frame of the Trays layout for the Content Server. In particular, the left-frame mini-search requires a prediction of the full URL, not just the relative URL.

2. The secondary URL (the #xml-http... piece following the PDF URL) that does highlighting for PDF documents.

Without any additional configuration, the BrowserUrlPath component augments the functionality of certain variables, so if SERVER_PORT has the value 433, then the component assumes the protocol is HTTPS instead of HTTP. Likewise, if SERVER_PORT does not have the value 433, then the component assumes the browser issued the request using HTTP and not HTTPS. This enhancement allows both a SSL (HTTPS) and non-SSL web server (HTTP) to access the same Content Server.

This component also has special functionality for WebDAV access. The configuration entry WebDavBaseUrl is augmented so that its usage is dynamic (its host and protocol vary using the "absolute" path rules).

Caution: The functionality for WebDAV access alters the behavior of CHECKOUT and OPEN functions on some Content Server pages, and alters some behavior in the Site Studio client.

4.8.2.2 Affected Idoc Script Variables and Functions

The BrowserUrlPath component overrides the computation of the following Idoc Script variables and functions:

• HttpBrowserFullCgiPath

• HttpWebRoot

• HttpCgiPath

• HttpAdminCgiPath

• HttpImagesRoot

• proxiedCgiWebUrl

• proxiedBrowserFullCgiWebUrl

The BrowserUrlPath component adds computation for the following variables:

• HttpBrowserFullWebRoot: Defines the full URL path to the Web root of the current Content Server using values supplied from the user's current browser's address bar. This variable is similar to HttpBrowserFullCgiPath except it is for the Web root instead.

• HttpAbsoluteWebRoot: Defines the universal full URL path to the web root of the current Content Server. It can have a different protocol or host name than the path in HttpBrowerFullWebRoot. For example, if the user specifies an IP address for the host name, the HttpBrowserFullWebRoot variable might pick up the IP address, but the HttpAbsoluteWebRoot variable would ignore it and use the appropriate internally configured host name.

• HttpAbsoluteCgiPath: Defines the universal full dynamic root URL for the current Content Server. This is the path that executes the plug-in code in the web server that makes calls for dynamic content from the Content Server. It can have a different protocol or host name than the path in HttpBrowserFullCgiPath. For example, if the user specifies an IP address for the host name, the HttpBrowserFullCgiPath variable might pick up the IP address, but the HttpAbsoluteCgiPath variable would ignore it and use the appropriately internally configured host name.

In the case of the browser path variables HttpBrowserFullCgiPath and HttpBrowserFullWebRoot, the implementation code determines what the user is currently using for protocol (HTTP versus HTTPS), port number, and host name in the browser. It bases this determination on what the web server receives in its request.

4.8.2.3 Determining the URL Path

The BrowserUrlPath component supports the following configuration entries for guessing the URL path as the browser determines it:

• HttpIgnoreWebServerInternalPortNumber: When set to true, this disables the use of the SERVER_PORT parameter. This entry is useful in a load balancing scenario where SERVER_PORT is not the port used by the browser, but is the port used by the load balancer to communicate with the web server. Enabling this entry will make it impossible (without the BrowserUrlPath component) for the Content Server to determine which port the browser used to access the web server. Without additional BrowserUrlPath configuration, this variable makes it impossible to both support an SSL and non-SSL address to the same Content Server. Using this variable prevents a load balancing configuration problem in which the load balancing server is using a different port number than the internal web server actually delivering the response to the request.

• HttpIgnoreServerNameForHostName: When set to true, this disables the fallback logic where if the HTTP_HOST parameter is missing, the Content Server will typically look for the parameter SERVER_NAME (the web server's self identification).

• HttpBrowserSSLPort: Only use this configuration entry if the SERVER_PORT entry is forwarded to the web server that communicates to the Content Server. This entry is used to decide whether a request is HTTPS or HTTP by comparing it with the SERVER_PORT parameter. The default SERVER_PORT value is 443. If you use HTTPS, but use a port other than 443, you must use this entry to set the expected HTTPS port number.

• HttpBrowserUseIsSslCookie: If you want to look in the cookie to see if it indicates whether to use SSL or not, set this entry to true.

• HttpBrowserIsSslCookieName: Only use this entry if the HttpBrowserUseIsSslCookie entry is enabled. Set the entry to the name of the cookie used to determine whether the server believes the browser is using SSL or not. The default is the cookie name UseSSL. The value of the cookie can be 1 or 0 (zero). If a cookie with this name is present, then it will supersede other rules for determining whether to use SSL.

• HttpBrowserUseHostAddressCookie: When set to true, this specifies to use a cookie to determine the full host name of the browser (the part between the protocol and the relative web address).

• HttpBrowserHostAddressCookieName: This entry is enabled only if HttpBrowserUseHostAddressCookie is enabled. Use this entry to specify the name of the cookie used to determine what the server believes is the browser's current host name. The host name part of the protocol can include the port number. For example, HttpbrowserHostAddressCookieName=myhost:81 would specify the host myhost using the webport 81. If you do use this cookie, then it is unlikely that you need to enable HttpBrowserUseIsSslCookie, because if you use myhost:433, that will translate to https://myhost/%rest-of-url%.

4.8.2.4 Changing Absolute Full Path Computation

The BrowserUrlPath component supports the following configuration entries for changing how the absolute full path is computed. This is useful for e-mail, where it is better to use a specific host name and protocol, even if the browser shows a different URL. This path is considered the absolute or universal path.

• HttpBrowserAbsoluteUrlHasRelativeSSL: When set to true, this variable allows a URL computed on the Content Info page to change from HTTP to HTTPS (or the other way if UseSSL is enabled in the config.cfg file), depending on what the Content Server determines as the current use in the user's browser. The change between HTTP and HTTPS also changes the computation of the URL for creating the e-mail body for the "email to" links. This configuration has no effect on automatically generated e-mail.

• HttpBrowserAlternateWebAddress: Specifies an alternate absolute host web address (host name plus optional port number). For example, HttpBrowserAlternateWebAddresss=host_name:447. This web address is used for the absolute path computation if the current SSL choice is different from the default for the Content Server. This configuration has no effect on automatically generated e-mail.

• HttpBrowserAbsoluteUrlUsesBrowserPath: When set to true, if browser path information can be computed, then the absolute path will use the browser path. This essentially turns off the absolute path except for background activities (such as sending notification e-mail).

4.8.2.5 Changing Administration Path Computation

The BrowserUrlPath component supports the following configuration entries for changing how paths are computed for Administration tray or top menu links. For example, the variable HttpAdminCgiPath, which retrieves the Admin Server CGI as a relative URL to the Admin Server, computes an administration path.

• HttpBrowserAdminUsesAbsolutePath: When set to true, instead of using the browser-based path (which is the default with the BrowserUrlPath component), the absolute path is used as the basis for computing administration paths, except for the protocol that is dictated by the configuration variable HttpBrowserUseAdminSSL.

• HttpBrowserUseAdminSSL: This configuration entry is only relevant if the HttpBrowserAdminUsesAbsolutePath variable is set. When set to true, this variable dictates the protocol in the administration paths (HTTP or HTTPS) even if HttpBrowserAbsoluteUrlHasRelativeSSL is set. The default value of HttpBrowserUseAdminSSL is the opposite of UseSSL. This allows the administration path to be nonstandard from the default URL constructions for all other paths. The variable HttpBrowserAlternateWebAddress, if set, can be used to also give the administration path a different web address in the case that HttpBrowserUseAdminSSL is set to the opposite of UseSSL.

For further information on variables and enabling the BrowserUrlPath component, see the Oracle Fusion Middleware Idoc Script Reference Guide and the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite for your operating system.

4.8.3 Extended User Attributes

The Extended User Attributes component enables administrators to add extended security attributes to Content Server users. The extended security attributes are merged into pre-existing user attributes and enable additional flexibility in managing users. For example, roles and accounts attributes can be added to external LDAP users without needing to perform internal setup. Also, roles and accounts attributes can be added to users for a customized application separately from base user attributes.

The Extended User Attributes component is installed (enabled) by default with Content Server. Services installed for the Extended User Attributes component are described in the Oracle Fusion Middleware Services Reference Guide for Unversal Content Management.

This section covers the following Extended User Attributes topics:

• "ExtUserAttribInfo ResultSet"

• "Configuration Variable for Extended User Attributes"

In addition to these resources, there are added queries which can be used to gather data for extended user attributes. The queries can be viewed in the Component Wizard or by looking in the UCM_ORACLE_HOME/ucm/idc/components/ExtendedUserAttributes/resources/extendeduserattributes_query.htm file.

4.8.3.1 ExtUserAttribInfo ResultSet

ExtUserAttribInfo is the ResultSet used by the Content Server to handle extended user attributes. It is similar to the UserAttribInfo ResultSet used for handling regular user attributes, with some additional information.

This ResultSet has three columns. You can supply one attribute per row or multiple attributes on a single row (per application). The following columns are included:

• dUserName: The user whose attributes are being described.

• dApplication: The application to which those attributes are linked.

• AttributeInfo: The attribute information. This is a comma-separated entry consisting of three items:

  • attribute type: usually either a role or account, depending on if a security group or account is being defined for the user

  • attribute name: the title of the role or account

  • attribute privilege: a definition of rights given to the user. Rights are defined according to UNIX conventions:

    • 1: read permisson

    • 2: write permission

    • 4: delete permission

    • 8: admin

    For example, the entry role,contributor,3 gives the user permission to read and write in the contributor security group.

    Multiple AttributeInfo entries can be added in a single row, separated by commas. For example, this entry adds two attributes into the AttributeInfo row: role,guest,15,account,\#all,15.

The following is an example of this ResultSet:

@ResultSet ExtUserAttribInfo
3
dUserName
dApplication
AttributeInfo
jsmith
appl
role,contributor,15
jsmith
app2
account,abc,15,account,xyz,15
@end

4.8.3.2 Configuration Variable for Extended User Attributes

The following configuration variable can be set in Content Server and is useful if you are working with default attributes:

• DefaultAttributesCacheTimeoutInSeconds: Defines how long the default attribute cache remains active (default = 600).

4.8.4 Filter Data Input

The Content Server can be customized to filter data input for illegal or corruptive HTML constructs by using the encodeHtml Idoc Script function and a filter hook to automatically scrub all input data for dangerous HTML constructions. The encodeHtml function can be applied to a specific string. The HtmlDataInputFilterLevel configuration variable can be used to apply a level of encoding to filter all data input to the Content Server.

This section covers the following topics:

• "encodeHtml Function"

• "HtmlDataInputFilterLevel Configuration Variable"

4.8.4.1 encodeHtml Function

The encodeHtml Idoc function can be used to filter data input for illegal or corrupted HTML constructs. The output is an encoded string. The encodeHtml function is applied by default to the discussions in the Threaded Discussions component.

The encodeHtml function is generally used at the exceptsafe or higher level of encoding because the HtmlDataInputFilterLevel configuration variable will already have been encoded as unsafe (assuming it uses the default configuration).

The encodeHtml function is defined as follows:

encodeHtml (string, rule, wordbreakrules)

• string: The string to encode.

• rule: The rule to apply when encoding HTML constructs. The following values are allowed:

  • none: No conversion is done to HTML constructs.

  • unsafe: Only well-known unsafe script tags are encoded. The list includes: script, applet, object, html, body, head, form, input, select, option, textarea.

  • exceptsafe: Only well-known safe script tags are not encoded. The list includes: font, span, strong, p, b, i, br, a, img, hr, center, link, blockquote, bq, fn, note, tab, code, credit, del, dfn, em, h1, h2, h3, h4, h5, blink, s, small, sub, sup, tt, u, ins, kbd, q, person, samp, var, ul, li, math, over, left, right, text, above, below, bar, dot, ddot, hat, tilde, vec, sqrt, root, of, array, row, item.

  • lfexceptsafe: (Recommended where extended comments are entered by a user and they want to preserve the line feed breaks of the original text.) Similar to exceptsafe, however, line feed (ASCII 10) characters are turned into HTML break tags (br). Line feeds inside of HTML tags are not turned into break tags. The following script tags that are safe with exceptsafe are not safe with lfexceptsafe: br, p, ul, li.

  Except for the rule none, all the rules have special HTML comment handling. In particular, all HTML comments are allowed through the filter. However, when inside an HTML comment, all less than (<) and greater than (>) symbols are encoded. This does not apply to the HTML closing signature (-->). Also, if there is an unterminated comment, the encoding function appends the HTML comment close signature (-->).

  Additionally, except for the rule none, any attribute value located inside a tag has any parenthesis encoded to %28 (for '(') or %29 (for ')'). Otherwise, if any character is escaped it is escaped using the XML (&xxxx;) type encoding.

  wordbreakrules: This is an optional parameter that specifies if long strings without space characters are to be broken up and what maximum word size to apply. Either the string wordbreak or nowordbreak can be specified. This parameter can be used with any of the encodeHtml rules. The default is to turn on wordbreak if the rule lfexceptsafe is specified, and to use a maxlinelength of 120 characters.

  The additional parameter maxlinelength=xxx can be used with the wordbreak parameter to specify a desired maximum line length. For example:

  encodeHtml ("exceptsafe", "<bad> text", "wordbreak, maxlinelength=80")
  

  The wordbreak functionality is only usable by the encodeHtml function because the function is used for display and not applied before the data is stored.

For information about Idoc Script see the Oracle Fusion Middleware Idoc Script Reference Guide.

4.8.4.2 HtmlDataInputFilterLevel Configuration Variable

The HtmlDataInputFilterLevel configuration variable can be used to apply a level of encoding to filter all input data to the Content Server for bad HTML constructions. The HtmlDataInputEncodingRulesForSpecialFields table in the std_resources.htm file is used for special case encoding rules and may override this configuration entry for certain parameters.

Note that if you change the HtmlDataInputFilterLevel value, you must restart the Content Server.

Using the HtmlDataInputFilterLevel variable has no effect on the behavior of the Idoc Script encodeHtml function.

You can set the HtmlDataInputFilterLevel configuration variable to the following values:

• none: (Not recommended.) All filtering is turned off.

• unsafe: (Default. Recommended.) Protects against bad HTML constructions. Examples of bad constructions include: script, applet, object, html, body, head, form, input, select, option, textarea.

• exceptsafe: (Not recommended.) Allows only well known safe constructions through the filter. If exceptsafe is chosen, then the unsafe option will be applied to requests using GET style requests. Doing a higher level of encoding on GET requests breaks Content Server operation because <$...$> and other tags are routinely passed in as part of the parameter data or URLs. The higher level of filtering is only applied to non-scriptable services (those services that are usually called with POST).

  Examples of well known safe constructions include: font, span, strong, p, b, i, br, a, img, hr, center, link, blockquote, bq, fn, note, tab, code, credit, del, dfn, em, h1, h2, h3, h4, h5, blink, s, small, sub, sup, tt, u, ins, kbd, q, person, samp, var, ul, li, math, over, left, right, text, above, below, bar, dot, ddot, hat, tilde, vec, sqrt, root, of, array, row, item.

See the encodeHtml Function rule description for information about HTML comment handling, which also applies to HtmlDataInputFilterLevel configuration values.

The value lfexceptsafe is not supported for the HtmlDataInputFilterLevel configuration variable. It is only supported with the encodeHtml function.