iOS 7 and captive portal — a guide to captive portal requirements

The release of iOS 7 created a lot of issues to captive portal technology providers, splash pages desgners and hotspots in general.

Apple changed completely the way any iPhone performs the test to see if the device is connected behind a Captive Portal, so most implementations stopped working.

Here in Tanaza we collected all the devices that we had in our lab, as well as in the neighbours startups, and decided to spend one entire day to perform tests. We now are happy to share what we discovered in this knowledge base article, summarized in the following.

Captive Portal automatic detection, avoid login popups

Scenario

When “Captive Portal” functionalities (alias “External Splash Page” in the Tanaza configuration) are enabled on an SSID , the access point filters all the requests sent by a client and allows/ denies the user access to internet based on a policy defined on the splash page.

In this scenario what happens is that when a user connects to that specific SSID, no matter what site he is asking for, the user will be redirected to the splash page defined in the tanaza configuration.

Since the users is not aware that he is not allowed access to internet, unless he opens a browser and tries to surf, all the Operative Systems (desktop and mobile ones) have developed a strategy through which they find out if they are behind a captive portal.
In case when they detect a captive portal a popup like brower is started asking the user to login to the captive portal.

Problem

These popup like brower can have some limitations (cookies not enabled, javascript disabled, anonimous session) and usually do not allow the user to experience a splash page correctly.

>> Read more

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.