Ask HN: Is it possible to escape captive portal webview limitations?

1 points by remohexa 40 days ago | 2 comments

I built a local media sharing website that runs entirely on a Pi hotspot. The main idea was to rely on Android's captive portal mechanism.

When an Android device connects to a network, it checks a specific URL (connectivitycheck.gstatic.com/generate_204). If the response is 204, it won't trigger anything, but if it receives something else (like 302), it will open that page inside a sandboxed webview and follow the "Location" header if it is present.

I used dnsmasq to spoof that URL and return the required response code. To my surprise, it actually worked, but only then did I discover that captive portals are sandboxed by default. The whole website is working as it should, with the only missing feature being that I can't select any type of files.

I'm curious if anyone here has ever experimented with captive portals before. Is there any way to open the user's browser? I feel like I might lose the user interest if I prompt them with a url to open in their browser.

skyberrys 40 days ago |

My Rpi runs a startup script that full screens a C++ program. So to the user it feels like it's the only user interface for the Pi, they don't see the desktop (except for a brief flash during startup, but then it's covered by the running startup script.

remohexa 40 days ago | |

That makes sense you're controlling the whole environment.

Out of curiosity though, why keep a DE at all if the user won't ever interact with it? What prevents you from getting rid of it entirely?

But as for my case, I don't have access to the user's device. I'm giving them an experience through a website on their phone once they're connected to a Wi-Fi network, so I can't really control their screen or go beyond the browser limitations.