Customizing Content Server Communication

This chapter provides information on how to customize access to and communication with a Content Server instance.

This chapter covers the following topics:

• Login/Logout Customization

• Browser URL Customization

• Extended User Attributes

Login/Logout Customization

The ExtranetLook component can be used to customize user access by suppressing the interface for users who are not authenticated by an Oracle WebLogic Server user store through error and challenge pages issued by the web server. For information about changing the interface, see Alter the Anonymous User Interface in Developing with Oracle WebCenter Content.

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

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 a Content Server instance deployed on an Oracle WebLogic Server domain and located behind a load balancer.

This section covers the following topics:

• About BrowserUrlPath Customization

• Affected Idoc Script Variables and Functions

• Determining the URL Path

• Changing Absolute Full Path Computation

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 native 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 instance can be accessed simultaneously by websites using HTTP and HTTPS. You then must apply the BrowserUrlPath component to enable the Content Server instance 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 may be placed in the IntradocDir/config/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 instance 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 instance.

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

1. Automatic creation of URLs in the side frame of the Trays layout for the Content Server instance. In particular, the side 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 instance.

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.

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

The BrowserUrlPath component adds computation for the following variables:

• HttpBrowserFullWebRoot: Defines the full URL path to the web root of the current Content Server instance 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 instance. 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 instance. This is the path that executes the plug-in code in the web server that makes calls for dynamic content from the Content Server instance. 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.

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 instance to determine which port the browser used to access the web server. Without additional BrowserUrlPath configuration, this variable makes it impossible to both support a SSL and non-SSL address to the same Content Server instance. 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 instance. 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%.

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 email, 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 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 email 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 instance. 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).

Extended User Attributes

The ExtendedUserAttributes 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 ExtendedUserAttributes component is installed (enabled) by default with Content Server. Services installed for the ExtendedUserAttributes component are described in the Extended User Attributes Services in Services Reference for Oracle WebCenter Content.

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 WC_CONTENT_ORACLE_HOME/ucm/idc/components/ExtendedUserAttributes/resources/extendeduserattributes_query.htm file.

ExtUserAttribInfo ResultSet

ExtUserAttribInfo is the ResultSet used by 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 permission

    • 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

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).