Captive Portal Page Customization - Configuration Examples

2. Configuration Examples

2.5 Captive Portal Page Customization

Each of the captive portal pages can be fully customized to suit the specific customer’s requirements and the customization can be performed by anyone who is familiar with HTML editing. Customized login, welcome, fail and agreement pages are typically based on the default pages included with the WiNG 5 system which are downloaded, modified then uploaded back to the WiNG 5 devices or deployed on an external HTTP server.

The following highlights the procedure used for customizing captive portal pages when the pages are hosted on a WiNG 5 device.

1. Create a captive portal with the web page source set to Internal. This will generate the required default pages on the WiNG 5 device which can then be downloaded and modified. Ensure the correct connection mode (HTTP or HTTPS) is defined in the captive portal policy as this impacts the HTML code in the pages.

2. Using TFTP or FTP download the login.html, welcome.html, fail.html and agreement.html pages from the WiNG 5 device. The pages will be located in the flash:/hotsport/captiveportal -policy-name> folder on the device.

3. Customize each page following the guidelines in this section so that mandatory elements are maintained.

4. If customized pages are hosted on a WiNG 5 device, modify the captive portal policy so that the web page source is set to Advanced. This will ensure that the customized pages are not overwritten with default pages.

5. Upload the customized pages and images onto the WiNG 5 device.

2.5.1 Captive Portal Policy

When customized captive portal pages are hosted on a WiNG 5 device the web page source in the captive portal policy must be changed from Internal to Advanced. This ensures that the customized pages will not be overwritten by the default pages if the captive portal policy is modified at a later date.

Page 94 If the customized captive portal pages are being hosted on an external HTTP server, a DNS whitelist policy will need to be defined, the web page source changed to Externally Hosted and the URL for each page defined. Externally hosted captive portal pages are covered in section 2.6.

2.5.2 Customizing Pages

Each captive portal page includes standard HTML elements which can be customized as well as

mandatory elements which must be maintained. The default pages include standard CSS which provides the formatting, layout and colors for the pages as well as various java scripts which are used to pass information to the WiNG 5 device performing the capture and redirection. The login and welcome pages also include a HTML forms which are used to authenticate and logout the users.

When the default pages are generated the appropriate java and form scripts are automatically generated in the default HTML pages. This includes if the terms and conditions page is required as well as the TCP port used by the captive portal service. While these variables can be modified it is recommended that the terms and conditions requirement and correct connection mode are defined prior to generating the default pages that are being modified.

2.5.2.1 Login Page

The login.html page includes two java scripts and a HTML form which must be maintained in the customized page. The java scripts must be included as -is with no modification; however the HTML form can be reformatted to suit the specific application as long as the action, method and input strings, names and values are maintained:

Java Script (between the </head> and <body> tags):

//Function to get param value from URL.

function getQueryVariable(variable) {

var query = window.location.search.substring(1);

var vars = query.split("?");

for (var i=0;i<vars.length;i++) { var pair = vars[i].split("=");

Page 95

document.getElementById('f_pass').value = "";

return true;}

</script>

HTML Form (between the <body> and </body> tags):

<form name="frmLogin" id="frmLogin" action="/cgi -bin/hslogin.cgi" method="POST" onReset="return clear()"

onSubmit="return check()">

</tr>

</tr>

<tr>

</td>

</tr>

<tr>

<td colspan="2" class="form-message"><input name="agree" value="yes" type="checkbox">I agree to these <a href="agreement.html" target="_blank">terms and conditions</a></td>

</tr>

<tr>

</tr>

<td colspan="2" class="form-message">Please contact the front desk if you have not been issued a username and password.</td>

</tr>

Page 96

</tbody></form>

</table>

Java Script (before the </body> tags):

var hs_server = "NONE";

var port = 444;

var postToUrl = "/cgi-bin/hslogin.cgi";

hs_server = getQueryVariable("hs_server");

Qv = getQueryVariable("Qv");

postToUrl = ":" + port + postToUrl;

document.getElementById("f_hs_server").value = hs_server document.getElementById("f_Qv").value = Qv

document.getElementById("frmLogin").action = "https://" + hs_server + postToUrl;

</script>

Page 97

2.5.2.2 Welcome Page

The welcome.html page includes various java scripts and a HTML form. Some java scripts can be optionally removed if required as they are used to display the remaining time for the session, however the first and last java scripts must be maintained as-is for the logout URL to function. The HTML form can be reformatted to suit the specific application as long as the action, method and input strings, names and values are maintained. If the remaining time is not required, these elements can be safely removed from the form table:

Java Script (between the </head> and <body> tags):

//Function to get param value from URL.

function getQueryVariable(variable) {

var query = window.location.search.substring(1);

var vars = query.split("?");

for (var i=0;i<vars.length;i++) { var pair = vars[i].split("=");

//Function to get param value from URL.

function getQueryVariable(variable) {

Page 98

Page 99

HTML Form (between the <body> and </body> tags):

<tbody>

<tr>

</td>

</tr>

<tr>

<td colspan="2" class="form-text" style="text-align: center;">Session Time Remaining:</td>

</tr>

</tr>

<td colspan="2" style="text-align: center;"><input name="submit" value="Disconnect"

Page 100

type="submit"></td>

</tr>

<tr>

</tr>

<tr>

</tr>

<p class="content-message">Click Disconnect to end this session.</p>

</tbody></form>

</table>

Java Script (before the </body> tag):

var hs_server = "NONE";

var port = 444;

var postToUrl = "/cgi-bin/hslogout.cgi";

hs_server = getQueryVariable("hs_server");

Qv = getQueryVariable("Qv");

postToUrl = ":" + port + postToUrl;

document.getElementById("f_hs_server").value = hs_server document.getElementById("f_Qv").value = Qv

document.getElementById("frmLogin").action = "https://" + hs_server + postToUrl;

</script>

Page 101

2.5.2.3 Failed Page

The fail.html page includes various java scripts and a URL that redirects the user back to the login page.

All the java scripts can be optionally removed if required:

Java Script (between the </head> and <body> tags):

//Function to get param value from URL.

function getQueryVariable(variable) {

var query = window.location.search.substring(1);

var vars = query.split("?");

for (var i=0;i<vars.length;i++) { var pair = vars[i].split("=");

Logout URL (between in the <body> and </body> tags):

<a class="NAV" href="/TMELABS-GUEST/login.html">Try Again</>

Java Script (between the <body> </body> tags):

Page 102

listenEvent(window, 'load', function() { var timeout = getTimeout();

var txt = '';

if(timeout==0 || timeout==-1) { } else {

txt="<center><h2>Authentication Failed.</h2></center><br><center><h4>Your allotted time has expired.<br/>Please purchase a new voucher.</h4></center><br><br><br><center>"

}

document.getElementById('txt').innerHTML = txt;

});

})();

</script>

Java Script (before the </body> tag):

postToUrl = "https://" + hs_server + ":" + port + "/";

var links = document.getElementsByTagName("a");

for (var i=0;i<links.length;i++)

links[i].href = links[i].href + "?hs_server=" + hs_server;

links[i].href = links[i].href + "?Qv=" + Qv }

}

</script>

Page 103

2.5.2.4 Agreement Page

The agreement.html page includes one java script which must be maintained as -is:

Java Script (before the </body> tag:

postToUrl = ":" + port + postToUrl;

document.getElementById("f_hs_server").value = hs_server document.getElementById("f_Qv").value = Qv

document.getElementById("frmLogin").action = "h ttps://" + hs_server + postToUrl;

</script>

2.5.3 Distributing Customized Pages

Customized pages can be uploaded individually to individual devices using the copy command in the CLI as well as the file management facility in the operations tab within the WiNG 5 UI. Individual file uploads are fine when the captive portal pages are hosted on a small number of devices, however this is very inefficient when distributing customized captive portal pages to large numbers of devices such as remote Access Points.

To address this limitation WiNG 5.4 includes various enhancements to aid in simplifying the distribution of customized pages to remote Access Points. Both enhancements allow a .tar archive of the customized content to be uploaded to the Controller. The archive is assigned to the captive portal policy so that the Controller knows which pages to deploy for each captive portal enabled Wireless LAN. The archived pages can either be automatically uploaded to the remote Access Points upon adoption or distributed using the CLI or WiNG 5 UI.



Note: The .tar file must b e compatible with Linux. When archiving files using Windows it is recommended that WinAce or IZArc b e used as the .tar files from other Windows applications may not b e compatible.

Page 104

2.5.3.1 Web Page Auto Upload

The web page auto upload enhancement allows customized pages to be automatically distributed to remote Access Points upon adoption. Upon adoption each Access Point will request the pages from the Controller. If the pages on the Controller are newer than the pages on the Access Point, the Controller will upload the .tar archive to the Access Point over MINT. The Access Points will then un-tar the archive and install the pages into the appropriate directory.

1 Using the Web-UI select Operations  <device>  Captive Portal Pages  CP Page Image File. In the Captive Portal List select the captive portal policy the pages apply to then enter the TFTP or FTP server information where the .tar archive resides and the Path / Filename. Click Load Image. Note for redundant Controller deployments the archive will need to be installed onto both Controllers:

2 Once uploaded a dialog message will be displayed. Click OK:

Page 105 3 Once the .tar archive has been uploaded to the Controller(s), modify the captive portal policy

and enable the Web Page Auto Upload option. Note that this only applies when the Advanced web page source option is selected. Click OK then Exit:

4 Commit and Save the changes:

Running-Configuration Changes:

server host virtual.tmelabs.local webpage-location advanced use aaa-policy EXTERNAL-AAA webpage-auto-upload

Page 106

2.5.3.2 Captive Portal Page Upload

Secondly the customized pages and content can be distributed to remote Access Points using the captive-portal-page-upload command or Captive Portal Pages within the WiNG 5 UI. For this feature the customized pages and content are archived (tar) then distributed to the remote Access Points. The pages can be distributed to individual remote Access Points, Access Points in a specific RF Domain or all Access Points.

Page 107 2 Once uploaded a dialog message will be displayed. Click OK:

3 Using the Web-UI select Operations  <rf-domain-name>. In the Captive Portal List select the captive portal policy the pages apply to. Verify the Upload Via RF-Domain option is selected then click Upload Pages. The status of the upload will be displayed in the Upload History window:

Page 108

In document WiNG 5.X How-To Guide (Page 93-108)