Page-Based Template Proxying
This section discusses:
Proxying and URL conversion.
Anchor tag conversions.
Form tag conversions.
JavaScript conversions.
The following discussion applies only to content that is not in the simple URL format.
See Portal URL Formats.
When processing page-based templates, the portal servlet uses a process called proxying to help ensure that users always stay within the context of the portal and to ensure that familiar portal features, such as the universal navigation header, do not disappear when a user clicks a link.
When users sign in to a PeopleSoft portal, they sign in to a web server on which the portal servlet is running. The portal servlet processes all the HTML that isn’t in the simple URL format, converting all URL references to point to the portal web server rather than the original URL. The original URL is still necessary to retrieve the requested content; it is stored in the new URL in the URL query string parameter. The portal servlet proxies all links and all form actions in this manner. Additionally, it converts any relative URLs into absolute URLs.
As an example, imagine that a user requests a page from an external website through a proxied link in the portal. The request arrives at the portal web server, invoking the portal servlet. The portal servlet then programmatically retrieves the page from the web server associated with the requested page. It proxies all the links on the retrieved response and sends the page (the contents of the HTTP response) back to the browser, formatted as the user would expect within the portal.
Converting Relative URLs to Absolute URLs
The use of relative URLs is common in web page design for external content. They are often used when a web page includes links to content on the same web server that the page is on. This works fine when a browser communicates directly with a web server because no ambiguity exists about where the relative URL points. However, because the portal servlet—and the proxying process—is placed between the browser and the target page, relative URLs become relative to the portal web server instead of the original target server. To prevent this from occurring and causing broken links, part of the proxying process includes the conversion of all relative URLs to absolute URLs. The following examples show the original, relative version of an HTML tag and the rewritten absolute version created by the portal servlet.
The following example shows a relative tag:
<IMG src="/image/cache/image.gif" lowsrc="/image/cache/image2.gif">
The following example shows an absolute tag:
<IMG src="http://originalserver/image/cache/image.gif"
lowsrc="http://originalserver/image/cache/image2.gif">
The portal servlet rewrites all anchor tags so that their src attributes direct the browser’s request to the portal web server instead of the server that created the URL. After rewriting the anchor tag, the portal servlet can determine whether the target URL should be wrapped with a template.
Old Anchor Tag
The following example shows an old anchor tag:
<a src=http://server/targetpage.html?Action=New>New Anchor Tag
The following example shows a new anchor tag:
<a src=http://portalserver/psp/ps/EMPLOYEE/NODE/e/?url=http%3a%2f%2fserver%2ftargetpage.html%3fAction%3dNew>Similar to anchor tags, all Form tags must have their Action attributes rewritten. However, with Form tags, the original URL is captured in a hidden form field instead of a query string parameter.
Old Form Tag
The following example shows an old Form tag:
<form action=http://server/targetpage.html>New Form Tag
The following example shows a new Form tag:
<form action=http://portalserver/psp/ps/EMPLOYEE/NODE/e>
<input type=hidden name=URL>
http://server/targetpage.html
</input>The portal servlet ensures that URL references contained in JavaScript are rewritten to point to the portal servlet instead of their original reference.