Human readable URL mappings for virtual portals

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

http://www.ibm.com:10039/wps/portal/tivoli

We can pass the human readable URL of a virtual portal to its users. They can then use it to access their virtual portal.

When we create a virtual portal, specify the human readable URL as required by the 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.

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

wps.vp.internal_ID_of_the_virtual_portal

The portal installation uses this unique name to identify and access the virtual portal unambiguously. xmlaccess.sh 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.

See URL mappings.

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 xmlaccess.sh 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, we base the URL filtering rules of a security proxy on the URL Mappings defined. Block all URLs by default and explicitly enable the defined URL Mappings only.

4. A URL mapping 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 for portal resources must start with...
   wps/portal/vp_1

   ...for example...

   wps/portal/vp_1/url_1
   wps/portal/vp_1/url_2

   Within this virtual portal, a URL mapping such as...

   wps/portal/url_1

   ...is not valid, as the portion vp_1 of the URL Context is missing.

   • There are some strings 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

     For more information see the topic about Restrictions to names for URL mapping contexts.

Parent Shaping the user experience

Related tasks:
URL mapping
Technotes for virtual portals