+

Search Tips   |   Advanced Search

URL mappings for virtual portals

We can provide human readable URLs for users to access their virtual portals. For example, we can give each virtual portal a human readable URL, such as...

When creating a virtual portal, we specify the human readable URL as required by your business environment. The URL mapping specified is assigned to the virtual portal during its initialization. The URL mapping points to the content root of the virtual portal.

Note: URL mappings were deprecated with HCL WebSphere Portal v8.5. Use friendly URLs instead. URL mappings are still used for internal purposes in the portal, for example, to map virtual portals.

Internally, this URL mapping corresponds to a unique name...

The portal installation uses this unique name to identify and access the virtual portal unambiguously. The XML configuration interface and the Portal Scripting Interface also use this URL mapping to identify the virtual portal.

We can also specify extra URL mappings for a virtual portal, both for the content root or for other content of the virtual portal, for example, a page in the navigation of the virtual portal.

All URL mappings use the same context root and servlet name in the URL. This setting applies to both the initial URL mapping of a virtual portal and any additional URL mappings that we might create for it.

  1. There is a 1:1 relation between a virtual portal and its initial URL Mapping. Each mapped URL points to the root content node of one virtual portal. We cannot use the same URL Mapping for two different virtual portals.

  2. We must not delete or modify the initial URL Mapping for a virtual portal or modify its unique name. Deleting this URL Mapping or modifying its unique name makes the virtual portal unusable. This setting is independent of whether we use the administration portlets URL Mapping or Custom Unique Names or the XML configuration interface to change the URL Mapping.

  3. If we use an external security manager, such as Tivoli Access Manager, we can restrict the usage of virtual portals using the URL Mappings. To restrict, you base the URL filtering rules of a security proxy on the URL Mappings that we defined. Block all URLs by default and explicitly enable the defined URL Mappings only.

  4. A URL mapping or friendly URL defined for a resource in a particular virtual portal must use the same URL context as the human readable URL context for that virtual portal itself. Example: In a virtual portal that uses the human readable URL mapping wps/portal/vp_1, all URL mappings or friendly URLs for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal, a URL mapping or friendly URL such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.

  5. There are some strings that we cannot use as URL mappings for virtual portals, for example vp. These strings are reserved names and correspond with URL codec names. They are listed in the following: 

      a0,    a0_1,   a0_2,   a0_3,  a1,    a2, a3,
base64xml
b0,    b0_1,   b0_2,   b0_3,  b1,    b2, b3, 
c0,    c0_1,   c0_2,   c1,    c2,    c3, c4,  c4_1, c4_2, c4_3, c5, c6, c7, 
cxml,  cxml_1, cxml_2, cxmld, kcxml,
d0,    d1,     d2,     d3,    d4,    d5, dl2, dl3,  dl4,  delta
kcxml, nm1,    nm2,    nm3,   nm4,   p0, pw, 
resource,      sel,    s0,    t0,    vp, wml,
z0,    z0_1,   z0_2,   z0_3,  z1,    z2, z3

Parent topic: Shaping the user experience

References: