Talk:Captive portal

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

About re-inserting the link to Amazingports[edit]

The article contains links to several captive portal solutions, that use RADIUS as the main authentication protocol. To extend the informative value of the article a different kind of captive portal solution should also be included. Amazingports has such a different solution. Probably from an encyclopaedia's point of view, the similar solutions can exemplified by one of links and than the other links can be made pointing out different ways of achieving the same thing.

About having a list of software products at all[edit]

Captive portals, both as standalone software products and integrated components of larger systems, are so commonplace and prolific that maintanence of a list of such products is probably more trouble than it is worth. Such lists become nesting sites for cometitive link farming. It should probably just be removed entirely. (71.233.167.118 (talk) 02:24, 7 March 2014 (UTC))[reply]

Section about usability[edit]

In my opinion this article, or maybe a related article, needs a section about usability. Specifically it would be useful with a comparison between captive portals and password-protected networks (WEP/WPA). My experience is that the latter has much better usability, since once you have submitted the password, the device will always connect as long as the systems are operating normally. Should I just add this section here, or should we discuss contents and whether this section belongs elsewhere?

My rationale for adding such a section is for hotspot owners to understand the usability impact of using either implementation. Bjornte (talk) 18:43, 5 December 2014 (UTC)[reply]

Issues and critics missing[edit]

The process of displaying the captive portal builds on ugly hacks: Either IP spoofing or DNS spoofing or/and sending fraudulent content (I consider response headers part of entire XHR and thus as content). Information on what could happen to users with custom DNS servers set in their preferences, whether and how DNSSEC will affect this hack and so on are ... not present. -- Rillke (talk) 16:32, 19 December 2014 (UTC)[reply]

Circumvention through MAC cloning[edit]

No router is required. One can simply set the MAC address of the attacker's NIC. -- 2601:644:0:C177:EC0D:EAD3:9D37:D9CB (talk) 12:03, 9 July 2019 (UTC)[reply]

Why "captive"?[edit]

I'm puzzled by the use of the term "captive" in this context so perhaps others are too. If someone could add an explanation of that, I at least would find it a valuable addition to the article. Poihths (talk) 13:52, 15 March 2022 (UTC)[reply]

They use the word Captive becuase, until you login and/or agree to the terms of service for the WiFi hotspot you're connected too (via the special captive portal webpage), you're "held captive" in a sense, as all your internet request are redirected to the captive portal and thus you only get the captive portal webpage until then or you get nothing if your not using web browser such as with an email program. Note that some OS's include automatica captive portal detection and bring a window with the captive portal page contents for you to login with. Once you've either logged in or agreed to a TOS agreement then your allowed o freely access the internet, either indefinitely or in some cases for a set period of time such as couple hours. Notcharliechaplin (talk) 16:10, 9 September 2022 (UTC)[reply]

Add GrapheneOS Captive Portal Detection URL?[edit]

I was using the Captive Portal Controller on my Android phone and noticed that GrapheneOS had it's own implementation. Do we add this to the table containing detection URLs? ~crazy (talk) 09:37, 28 January 2024 (UTC)[reply]