6

I'm creating this landing page that's supposed to be triggered by a captive portal. on my landing page, there's a button to trigger open a <video> element which is then used to scan the QR code. By default, upon accessing the webcam or device's camera the browser would ask the user's permission first. So basically everything is working fine and all on the browser.

Upon lodging it as a landing page triggered by the captive portal, some inconsistencies arose. On most Android phones my colleagues have, they simply deny the permission by default. On some android devices, the popup message asking for permission is shown, and working as expected just like the browser version. On IOS devices, the popup simply gets blocked (not denied, but ignored) I know it is ignored on IOS because the error message is not even showing, as if no action is given to the popup by the captive portal.

I've read several forums on captive portals, all led me to believe that captive portals by nature are simply a lighter version of a built-in browser that simply doesn't have the capacity to run window.alert() and window.confirm() nor the ability to keep cookies. My "research" also led me to believe that captive portals have different sets of behavior unique to the OS, not the browser installed on that OS per se.

1 blog I read today, specifically the comment section, mentioned that from IOS 11.2 on, captive portals should already be able to run window.alert() and window.confirm(). However, upon testing it, this simply isn't the case.

So my question is, is there any way to work around this limitation, by still allowing users to decide whether to allow or deny camera access?

My "research" shows that it is impossible to redirect a captive portal to open on a browser programmatically and only a handful of phones have a captive portal that comes with the "open in browser" option.

Does anyone know any way to, say, intercept the permission popup in action and display it as just a normal HTML element then pass back the user response programmatically?

Thanks in advance! :)

Sumit
  • 2,242
  • 1
  • 24
  • 37
Ray Jonathan
  • 1,285
  • 1
  • 12
  • 21
  • "Upon lodging it" -- Do you mean "logging" or perhaps "registering"? Lodging something is providing it a place to sleep. – Stephen Ostermiller Apr 30 '22 at 12:20
  • 2
    QR codes on captive portals are used opposite way, like the QR code is shown to the user and then employee scan that QR code to grant access to that user. I'm afraid you cannot bypass this as its simply not supported by all devices yet, but other approaches like DNS captive portal where user have to open regular browser where camera works could be your solution. – Kazz May 06 '22 at 19:20

1 Answers1

0

Interfering with system UI flows is not possible. Running code tied to system UI must me tightly controlled to not allow user extorting schemes, like 'Do this with your phone to gain internet access'. Captive Portals from an OS vendor perspective are only about consenting or rejecting the terms of internet use through a provider.

You must change to a two-tiered approach, serving a captive portal and a landing page separately:

  1. Let users check the captive portal
  2. Serve your landing page when they use the browser.

To facilitate and prepare users for the 2nd tier, include a link to your landing page in your captive portal, saying something like 'Start using internet here'. Also have a look at the latest changes in Android and Apple's OSs with regard to Captive Portal API and Captive-Portal Identification in DHCP / RA. (via)

Think of the constrained captive portal as device side aspect, the rich UI landing page as a provider side aspect of accessing internet that can't be united for security reasons.

cachius
  • 1,743
  • 1
  • 8
  • 21