Handling Web Applications that use Non-Standard HTTP/S Ports
search cancel

Handling Web Applications that use Non-Standard HTTP/S Ports

book

Article ID: 174882

calendar_today

Updated On:

Products

Symantec ZTNA

Issue/Introduction

Handling Web Applications that use Non-Standard HTTP/S Ports

Resolution

Web Applications / Portals designed with a Local Area Network / Virtual Private Network "mentality" may contain references, either in the HTML pages or in AJAX scripts to URLs with non-standard ports (i.e., not TCP 80 for HTTP / TCP 443 for HTTPS).

This is a practice that might be used in legitimate business applications, such as VMware vSphere or various Oracle Business Applications. In the vast majority of the cases, the usage of non-standard ports will be done in a way that is transparent to the end-user, not as an initial page the user navigates to, but as a part of an internal flow.

Below diagram demonstrates a possible challenge:

non-standard_port.PNG

Without any special handling, the Web Application/Portal will either contain broken links or will not function properly. Web Application Server 2 can reside on the same machine as Web Application Server 1 and only have a different port, this does not change the issue.

Following steps are required to configure the system to support such non-standard web applications:

 

1. Define a separate Web Application for the non-standard port

In the Administration Portal define a separate Web Application for the non-standard port. Make sure to define the port in the internal address. In order to avoid confusion, mark "Publish in Application Portal" as No (in the advanced settings).

custom_port_internal.PNG

2. Define an HTTP Response Custom Link Translation Rule

In the advanced settings of a Web Application representing Web Application Server 1 (not the newly created object), please click on "Edit Customer Rules" (if this capability does not appear in your portal, please open a support ticket to have it enabled).

 

Define the custom content rule according to the below:

custom_link_rule.PNG

Content Type - Can either remain blank, or, for optimization, can contain the content-type of the resource containing the reference to an internal address with a custom port, such as "application/json" or "application/javascript"

Message Type - Has to be set to "HTTP Response"

URI - Can either remain blank or contain specific URI that returns the resource containing the reference to an internal address with a custom port.

Source URL - A full or partial URL containing an internal address of Web Application Server 2 with a custom port.

Destination URL - A full or partial URL containing an external address of Web Application Server 2, accessible via Secure Access Cloud.

 

3. Optional (If CORS Policy Blocks the requests) - Define a Path Translation Rule

In some cases, if Web Application Server 1 has a strict CORS policy that would not allow browser/AJAX to call web-application-2-external address. While this case can be rare, in order to support it, the following change should be made to Destination URL parameters of the custom body rule:

Instead of web-application-2-external is should say: web-application-1-external/luminateto/web-application-2-external

This directive will cause the browser to send the request to a URI in Web Application Server 2 via a domain of Web Application Server 1 and a URI appended to /luminateto/web-application-2-external