7 ms·

I am currently writing captive portal support for a big-name internet provider. This article only scratches the surface of how difficult it all is. Each OS is d

I am currently writing captive portal support for a big-name internet provider. This article only scratches the surface of how difficult it all is. Each OS is different, and each is painfully undocumented

pretext-1 4y ago
Can you provide some examples?
- lukeboi 4y ago
  Sure. Rambling off the top of my head: On mobile OSes, the captive portal is opened in a sandboxed embedded browser. OS designers want to prevent the captive portal from being used maliciously, so they understandably block off a lot of functionality. Problem is they don’t tell you what features they turn off. I.e As far as I can tell iOS blocks off external links and ajax requests (!) On iOS you can’t close the captive portal programmatically. The user must submit an html form (or similar) and navigate to a new page. Only then will the OS check /mobile-hotspot-detect and realize that the user is connected to the internet and present the user a button to close the captive portal. This is very clunky and makes it impossible to make a sleek user experience Android automatically closes the captive portal when it detects a connection. This often confuses the user (why did my page suddenly disappear?) and makes it impossible to make a consistent mobile captive portal experience between iOS and android Androids kernel seems to have two separate, independent captive portal checks iOS only checks the content of the connectivity check endpoint, while android also checks for any form of a DNS redirect in its requests Microsoft checks against two different domains for a captive portal Many Non-stock android distros check against their own custom (and undocumented) endpoints There was a dhcp option recently introduced to help clean up this mess. Problem is, nobody supports it. Not even Apple (who seemed to have played a hand in the RFC) supports it Linux is a lost cause Figuring this all out took over a month of trial and error. Even then many of my conclusions are probably wrong. None of this is documented or standardized!
  - smashed 4y ago
    I've been there. I can relate to everything you said! The DHCP standard was such a waste of time. Ignore it completely, no client support whatsoever. Intercepting all plain HTTP traffic (just drop https) and responding with a 30x redirect to your captive portal web page seems to be the ad-hoc "standard". Your captive portal domain can be served under secured HTTPS just fine. I fully agree with the sandboxed browsers pain and absolute impossibility to get a nice consistent UX across platforms.
    - lukeboi 4y ago
      Totally agree. Like you said the method we converged on is to just redirect DNS requests + 303 users depending on if they’ve gotten through the portal yet. It seems to work fine. What’s most frustrating is that most off-the-shelf FOSS dns programs don’t let you do DNS redirects on a per-mac basis, leading us to in-house a decent amount of DNS code.
  - AceJohnny2 4y ago
    > None of this is documented or standardized! I mean, captive portals started out as a hack, then captive portal detection was a hack against that hack... It's effectively an antagonistic relationship.
    - hansel_der 4y ago
      somewhat reminiscient to cookie banners
ddevault 4y ago
Please don't build anti-features. They only happen because people like you and me agree to implement them. Push back against management. Tell them that you've done the research and it's a nightmare and you shouldn't move forward with it.
- jaimex2 4y ago
  Captive portals were around before modern browsers. The browsers made the mess not the other way around. Respect redirects over HTTP or gtfo.
- perryizgr8 4y ago
  I'm curious how would you rather implement things like airport wifi without a captive portal?
  - hansel_der 4y ago
    idk, just leave it out? it'll work
  - weberer 4y ago
    Just let people connect to wi-fi and use it without screwing with them. I don't really understand your question.
    - perryizgr8 4y ago
      Operating a good wifi network at scale is usually quite costly. It is a good idea in some settings to be able to monetize outsized users. For example, your first 30 minutes on the airport wifi can be free, and if you have to be there for longer than that, you can pay a fee for the next hour. Have you never considered this scenario?
      - ddevault 4y ago
        QoS, metering and caps, etc.
Nextgrid 4y ago
Is there a reason you can’t use EAP with unique usernames & passwords?

pretext-1 4y ago

Can you provide some examples?

lukeboi 4y ago
Sure. Rambling off the top of my head: On mobile OSes, the captive portal is opened in a sandboxed embedded browser. OS designers want to prevent the captive portal from being used maliciously, so they understandably block off a lot of functionality. Problem is they don’t tell you what features they turn off. I.e As far as I can tell iOS blocks off external links and ajax requests (!) On iOS you can’t close the captive portal programmatically. The user must submit an html form (or similar) and navigate to a new page. Only then will the OS check /mobile-hotspot-detect and realize that the user is connected to the internet and present the user a button to close the captive portal. This is very clunky and makes it impossible to make a sleek user experience Android automatically closes the captive portal when it detects a connection. This often confuses the user (why did my page suddenly disappear?) and makes it impossible to make a consistent mobile captive portal experience between iOS and android Androids kernel seems to have two separate, independent captive portal checks iOS only checks the content of the connectivity check endpoint, while android also checks for any form of a DNS redirect in its requests Microsoft checks against two different domains for a captive portal Many Non-stock android distros check against their own custom (and undocumented) endpoints There was a dhcp option recently introduced to help clean up this mess. Problem is, nobody supports it. Not even Apple (who seemed to have played a hand in the RFC) supports it Linux is a lost cause Figuring this all out took over a month of trial and error. Even then many of my conclusions are probably wrong. None of this is documented or standardized!
- smashed 4y ago
  I've been there. I can relate to everything you said! The DHCP standard was such a waste of time. Ignore it completely, no client support whatsoever. Intercepting all plain HTTP traffic (just drop https) and responding with a 30x redirect to your captive portal web page seems to be the ad-hoc "standard". Your captive portal domain can be served under secured HTTPS just fine. I fully agree with the sandboxed browsers pain and absolute impossibility to get a nice consistent UX across platforms.
  - lukeboi 4y ago
    Totally agree. Like you said the method we converged on is to just redirect DNS requests + 303 users depending on if they’ve gotten through the portal yet. It seems to work fine. What’s most frustrating is that most off-the-shelf FOSS dns programs don’t let you do DNS redirects on a per-mac basis, leading us to in-house a decent amount of DNS code.
- AceJohnny2 4y ago
  > None of this is documented or standardized! I mean, captive portals started out as a hack, then captive portal detection was a hack against that hack... It's effectively an antagonistic relationship.
  - hansel_der 4y ago
    somewhat reminiscient to cookie banners

ddevault 4y ago

Please don't build anti-features. They only happen because people like you and me agree to implement them. Push back against management. Tell them that you've done the research and it's a nightmare and you shouldn't move forward with it.

jaimex2 4y ago
Captive portals were around before modern browsers. The browsers made the mess not the other way around. Respect redirects over HTTP or gtfo.
perryizgr8 4y ago
I'm curious how would you rather implement things like airport wifi without a captive portal?
- hansel_der 4y ago
  idk, just leave it out? it'll work
- weberer 4y ago
  Just let people connect to wi-fi and use it without screwing with them. I don't really understand your question.
  - perryizgr8 4y ago
    Operating a good wifi network at scale is usually quite costly. It is a good idea in some settings to be able to monetize outsized users. For example, your first 30 minutes on the airport wifi can be free, and if you have to be there for longer than that, you can pay a fee for the next hour. Have you never considered this scenario?
    - ddevault 4y ago
      QoS, metering and caps, etc.

Nextgrid 4y ago

Is there a reason you can’t use EAP with unique usernames & passwords?