Responsive captive portal login page for Aruba wireless

 

Note: for an updated version of the login page which works on all current OS with Wi-Fi assist please visit the link below: 

https://gshaw0.wordpress.com/2017/09/03/responsive-captive-portal-for-aruba-wi-fi-updated-for-ios-cna/

 

During the course of the year we’ve ramped up the number of APs on our campus Wi-Fi network in order to increase take-up of BYOD and provide blanket coverage across all sites. We’ve been using the standard out-the-box Aruba login screen for authentication but have had feedback that it isn’t the easiest thing to use on mobile devices (particularly phones).

Fuelled by a large coffee and equally large chocolate dessert at lunch I decided to get creative and have a go at improving the login experience.

Aruba controller options

The default Aruba page is functional but is showing its age now, the controller allows you to change the background image and text but that’s about it unless you go for something more custom, as confirmed on one of the posts in the Aruba forums

Ref: http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Captive-Portal-not-resizing-to-fit-mible-device-screen/td-p/83968

In the controller options there’s an option to upload a custom login page, along with supporting files (referred to as Content in the Aruba interface). However it’s not easy to manage the additional files once they’ve been uploaded, which is a bit of a pain.

The Aruba manual linked below shows where to go in the web interface to customise the portal, just make sure you select the correct authentication profile for the SSID you want to edit!

Ref: http://community.arubanetworks.com/aruba/attachments/aruba/unified-wired-wireless-access/12922/2/customize-captive-portal.pdf

Responsive themes & styling

Fortunately one of the replies about using a custom page got me thinking and initially I looked to use the Verti template as suggested. Initial attempts to strip it down didn’t quite look right so I had a search for something simpler. Soon I’d found exactly what I wanted with the Grayscale Bootstrap theme

The beauty of this theme is in the simplicity of it, everything on one page and just a couple of images to tweak (along with the usual colour changing in CSS). Adding the Aruba code for the login form was fairly trivial, along with some tweaks to the CSS to increase the height of the fields so they’re easier to hit on a touch device.

For the background I used the very handy advanced search tools on Google Images to find a subtle background. A cropped version of this image from the Colorado Clouds blog did the trick nicely, along with the usual Photoshop layer-mask trick to fade out to a solid colour for the remainder of the page.

very handy options in Google Image Search

To reduce the number of supporting files that need to be uploaded to the Aruba controller I tried to embed as much as possible into the login page HTML file. Javascript and CSS were copied into the code  rather than referenced as files and images were encoded into base64 strings, a trick I’ve used a few times in the past with HTAs.

My previous favourite base64 converter website seems to have been taken down so I’m now using http://www.base64-image.de instead.

Informational text

A nice feature of the Grayscale template is the way the page is split into sections with shortcuts in the top menu bar. It made sense to put the AUP text in one of them rather than how it was displayed previously (in a slightly clumsy pop-up window).

To split the terms of use away from the intro text in the section I used a centered, 80% width div and styled <hr> tag which seem to work together pretty well on both desktop and mobile views.

Custom error handling

The Aruba manual lists a small Javascript that’s meant to handle any errors returned by the controller (e.g. failed login) and display it on the page. Unfortunately it didn’t seem to work when inserted into the new template whatever way we tried. My colleague Arturas Taleikis noticed that the controller adds a variable to the end of the login page URL and suggested that we create our own error handler instead.

We used the script from http://stackoverflow.com/questions/814613/how-to-read-get-data-from-a-url-using-javascript to read the error being returned then a short if statement to write a message in our chosen location above the login form.

The advantage to reading the errors this way was that we’re now able to customise and CSS style the message shown to the user. Contrary to the Aruba documentation I’ve seen 3 possible messages so far (Aruba only mention one); two of them dealing with failed login due to invalid credentials and one for authentication server timeout.

Web server maximum concurrent clients

After enabling the new login page we noticed that the Aruba controller was struggling to load the page after users connected to the SSID. Rebooting the controller didn’t help, although the first user to load the captive portal after the restart was able to log in at normal speed.

A bit of investigation revealed a setting on the controller that limits the maximum number of concurrent connections to the internal web server used to provide the captive portal and ours was set to the default of 25. It seems that this was sufficient for the standard login form but soon gets overwhelmed with a more complex page (total size of the page plus supporting files is still under 1MB though).

Ref: http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Captive-Portal-slow-timeout/td-p/73934
Ref: http://community.arubanetworks.com/t5/tkb/articleprintpage/tkb-id/ControllerBasedWLANs/article-id/147

To change the setting follow the information in the links above, or to save you time here’s the steps in abbreviated form 😉

• log into your Aruba controller’s Instant CLI using Putty or similar SSH client
• enter the console enable password and enter the commands that follow
• configure terminal
• web-server
• web-max-clients 100

The change applies immediately. Use the commands below to check that it’s applied as expected and also keep an eye on your CPU and memory stats as the more concurrent sessions you allow the more resource gets used on the controller.

Note the web-max-clients setting goes from 25-320 (may vary depending on your controller). In our case with ~500 active Wi-Fi users (last time we looked) a web-max-clients setting of 100 seems to be working well but this will likely vary dependent on your usage patterns.

• show web-server
• show cpuload
• show memory

Login page screenshots

The screenshots below show the login page on both phone and tablet \ desktop views, the bootstrap responsive element doing a great job as the page resizes 🙂

mobile phone view

desktop view (tablet is similar but uses the top menu from the phone style)