How to choose the Wi-Fi splash page that works best for you
Let’s start. We’re here to talk about Wi-Fi splash pages (Tanaza ones or external ones, it doesn’t matter) and why you should take your time to think about them.
3 reasons why splash pages are important:
Terms and conditions. Accepting them, the user consents to the use of his personal data.
Branding and advertisements. Users are reading your page carefully to go further and connect to your Wi-Fi, so take advantage of this and show engaging advertisements and offers.
Social login and data capture. Enabling social login, the login process becomes easy and quick. You can record all data that users give to you.
Give one-click access (no data required) to the Wi-Fi
Ask for e-mail and/or phone
Collect data
Once that you have decided which are your goals and which is your strategy, you are at the crossroads between the Tanaza splash page, a 3rd party splash page or designing your own one.
Here you find a comparative table that can help you decide what works best for you:
The different ways have many things in common, but here are some suggestions.
If you are using hardware from Meraki, Aruba Networks, Aerohive, you should choose a 3rd party splash page, because Tanaza doesn’t support these devices. Another reason to use a 3rd party splash page is the need for very specific apps like publishing weather information on the splash page, or exchanging banners.
If you want 100% control on HTML and 100% control of the user experience, you should definitely choose to cloud manage with Tanaza your own devices and then build your own splash page (keep in mind that this requires a lot of effort and strong IT skills, see specs).
Instead, if you don’t want to spend a lot of time creating your own splash page, if the included features are the ones you’re looking for, and you want a ready-for-use hotspot, with social login on 6 different social networks, up and running in 3 minutes… Tanaza splash page is your best option.
Don’t forget that only Tanaza “Social login” account includes also the access to thenew social dashboard, an essential powerful marketing tool that Tanaza has recently released.
Many customers are requesting Tanaza to support “Captive Portal”. We understood that there is definitely a need to clarify what Captive Portal capability is and how it is implemented in a cloud managed Wi-Fi Network.
We think that the best article that can clarify the relationship between hardware, cloud infrastructure, Radius server, captive portal capability, splash pages, accounting and client management comes from… Meraki!
So… here it is. Enjoy the precision of each single word of this article.
Many organizations have an existing user authentication or directory server that they would like to use to control access to the wireless LAN. Common server types include LDAP or Active Directory. Any type of authentication server with a RADIUS interface can be integrated with a Meraki wireless network. The cloud allows an administrator to configure multiple RADIUS servers for failover.
When an externally hosted RADIUS server is used with either MAC-based access control or WPA2-Enterprise with 802.1x authentication, the cloud managed APs must be able to reach the RADIUS server. The Meraki cloud offers a test tool that enables an administrator to verify connectivity of all of the APs to the RADIUS server, and to check a particular set of user credentials against the RADIUS server. The test tool appears under the Configure tab on the Access Control page.
When an externally hosted RADIUS server is used with sign-on splash page, an administrator can configure the Meraki wireless network to use an externally hosted RADIUS server for user authentication. The Meraki cloud acts as an intermediary in this configuration to provide (1) a consistent end user experience (e.g., the wireless user is not presented with the splash page again if he re-associates to another AP) and (2) RADIUS accounting features.
If the sign-on splash page is hosted by the Meraki cloud, the conversation is a straightforward RADIUS exchange between the Meraki cloud and the external RADIUS server.
If the sign-on splash page is itself externally hosted, the conversation involves exchanges between the splash page server, the Meraki cloud, and the RADIUS server. Specifically:
The wireless client associates with the Meraki wireless network.
The user makes an initial request for a URL in his web browser.
The Meraki AP redirects the user to a URL on the splash page server. (The administrator configures this URL in the Meraki cloud, under the Configure tab on the Splash Page page.) When the Meraki AP redirects the user to the splash page server, it includes the following HTTP parameters in the HTTP redirect:
continue_url: The URL that the user originally requested. This parameter may be interpreted by the splash page server to decide where the user should be redirected if he authenticates successfully.
login_url: The URL at the Meraki cloud to which the splash page server should send an HTTP POST with collected user credentials (see Step 4). This parameter is escaped to include the continue_url embedded within it, and should not be interpreted by the splash page server.
ap_mac: MAC address of the Meraki AP to which the user is associated.
ap_name: Name (if configured) of the Meraki AP to which the user is associated.
ap_tags: Tags (if configured) applied to the Meraki AP to which the user is associated.
mauth: An opaque string used by the Meraki cloud for authentication and security.
The external splash page server presents the user with a web form that captures the user’s credentials and causes the user to send an HTTP POST to the Meraki cloud, using the URL specified in login_url (see Step 3). In this HTTP POST, the server includes the following parameters:
username: The username that the wireless user provided to the splash page server.
password: The password that the wireless user provided to the splash page server.
success_url (optional): The URL to which the wireless user is redirected if he passes authentication. The splash page server can use this parameter to override the continue_url that the user originally requested.
The Meraki cloud receives the HTTP POST from the splash page server, and in turn, sends a RADIUS Access-Request to the external RADIUS server with the username and password.
The RADIUS server processes the RADIUS Access-Request from the Meraki cloud, and responds to the Meraki cloud with a RADIUS Access-Accept or Access-Reject. The RADIUS server may optionally send RADIUS attributes to the Meraki cloud to enforce over the wireless user.
The Meraki cloud processes the response from the RADIUS server and redirects the wireless user accordingly.
If the Meraki cloud receives an Access-Accept message from the RADIUS server, the user has successfully authenticated. The Meraki cloud redirects the user to the original URL he requested (continue_url), or the URL specified by the splash page server in the (optional)success_url (see Step 4).
If the Meraki cloud receives an Access-Reject message from the RADIUS server, the user has failed authentication and is redirected back to the splash page server’s URL (in Step 3).
Because the Meraki cloud needs to contact an external RADIUS server, the Meraki cloud must be able to reach the RADIUS server. This requirement may necessitate firewall changes that allow inbound connections to the RADIUS server. If the RADIUS server becomes temporarily unavailable, existing wireless clients (already authenticated) remain connected, but new wireless clients are unable to authenticate to access the network.
We are using technical and profiling cookies to give you the best experience on our Website. By continuing to use our Website without changing the settings, you consent to our use of cookies. Read More about Cookies
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
There are many types of rights on the images you find on-line:
