george-hawkins
commented
3 years ago Hello Daniel - it's really super to hear that someone is actually using my code. I put quite a lot of effort into but as far as I know you're the first person to try it. I hope it proves useful.
I'm not going to merge your PR but instead, I'm going to suggest a slightly different approach that uses the scheduler that already exists in the CaptivePortal class. I've documented that approach here:
https://github.com/george-hawkins/micropython-wifi-setup#idle-timeout
And you can see the changes involved in commit bb6114c.
Separately, I've also updated all the web resources to pull in the latest dependencies - so everything else is also up-to-date now.
I think the idea solution relating to security would be:
- For the device to use HTTPS rather than HTTP but unfortunately this is hard to support even in conventional captive portals as HTTPS really requires access to the public internet (in order for the client browser to be able to validate the certs involved).
- For the device to challenge you to enter a PIN that's either printed on the device or which it displays if it has some kind of LCD screen.
Requiring the person to enter a PIN would prove that they have physical possession of the device (and can see what's printed on it) and aren't just a random stranger who can see its WiFi signal.
The Captive Portal now can have a timeout. The idea is that it is shown only for a configurable amount of time, e.g. 15 minutes. After this timeout, the CP shuts down. This helps to prevent that a random person (i.e. a neighbor) can take over the device if the already-configured WiFi connection can't be established.
The default is
None, which is consistent with the previous behaviour (Captive Portal stays alive until someone establishes a connection).