|Version 6 (modified by anonymous, 5 years ago)|
Running a wireless community using a captive portal
This document lists the different models for giving internet access using a captive portals (note also that a single community can implement multiple models). For now, it is mostly written to clarify terminology. It does not attempt to discuss how each model relates to sustainability, or the considerable variations in policy that can occur within each model (is the user time limited, bandwidth limited, etc.). Over time, this document will list how suitable wifidog is for every model, and what features are missing.
Models for determining who has access
Models with users
Users can signup freely (possibly providing some mandatory information, typically an email address). Examples: http://www.ilesansfil.org/
When access is to be provided to an existing community of users. Examples: university campus, users of a public library, etc.
Users have to provide something in exchange of network access in a hotspot. Typically, bandwidth or access to their own hotspot. Example: Fon, wifree
Paid subscription & WISP
Access is provided when the user subscribe to some monthly service. Residential access from a WISP, an option on their cellular plan, etc.
Models without users
No attempt to maintain unique users is made whatsoever. The community simply wants to maintain locative or non-locative portals. Example: NYC wireless
Free tokens tied to purchase
Model in which a customer is provided with a one time use password equivalent with some unrelated purchase in a commercial venue (meal, coffee, etc)
Password of the day
Providing users in a venue with a daily changing password, distributed non-electronically (usually written on a whiteboard). The idea is to force users to physically come to the venue to gain access.
You buy access for a day or an hour using a credit card. Examples: Most typical commercial hotspot operators.
Just like prepaid cellphone.
Open access point
Just plugging in an access point with no access control or portal!
The model chosen will mostly determine the portal mechanic. An ideal captive portal system has three distinct “pages” involved in the connection process.
Welcome page (usually a login page, user does not yet have network access)
Disclaimer page (must be accepted for access, between Welcome and portal page, must be accepted each time or only once)
Portal page (user has network access)
Note that some models can have no Welcome page (Splash-only), or no Portal page (the portal redirects to the page originally requested by the browser once login and disclaimer stages have been completed. Explicit support for Disclaimer page isn't part of wifidog yet. Even once it is, many groups may decide that implicit acceptance is enough (so they will simply put the disclaimer on the login page).