I’m planning on using one of my Cores at work, where I’d have to connect to the local visitor WiFi network.
This will require in-browser authentication on a “Captive Portal”.
So I first set up the SSID for the open WiFi net, and get the Core connected to the WiFi channel, but all traffic gets captured by the portal, till the Core authenticates itself against the portal with an additional User/Password set.
This would normally be done manually by opening a browser that displays the portal login page, the user enters the credentials and from then on the traffic is released into the outside world.
Now with the Core I have no browser to enter credentials into, but I could imagine, that the incoming HTML could get forwarded to my phone or some other device (that is already connected to the network), where I could enter the credentials, send the response back to the Core who relays it back to the network - a bit like the first time connection of the Core to a new WiFi network with SSID/PWD works.
Is this thinkable and maybe possible to incorporate into Tinker app or any other Spark SW that is required for getting a Core connected to a network?
Hi @ScruffR - in theory you could have the Spark Core capture the captive portal HTML and forward it on to another device, which could then send the response back up the chain. However, this will be challenging at best.
Alternatively, you do not necessarily need to know what the HTML is from the captive portal, so long as you know the response necessary to get through. So you could, in theory, tell the Spark Core to send whatever information the captive portal is looking for (simulating a click of the ‘submit’ button with the appropriate user/password).
Neither of these solutions is particularly easy; the Spark Core (like other similar embedded systems) is not particularly well-designed for dealing with captive portals.
Thanks @zach - I feared it wouldn’t be easy and I’m aware of the difficulties embedded systems have in such an environment, but exactly this was the idea behind my question, to load of the hard work onto a more suitable device like a SmartPhone to do the hard work and the Core just to act as “man in the middle” till the task gets easy enough for the Core to take over and do the rest.
The problem with your suggestion only to push out the expected response, is that I don’t know the appropriat response beforehand (https and many different possible APs with ever changing PWDs).
So I thought of just reusing the already available path Smart Config seems to use to get in contact with the Core to tell it the SSID and WiFi password - but now when I think about it, I forgot that this is only an encrypted one-way broadcast only the Core understands.
The Core just receives data from the SmartPhone and cannot send anything back to the phone before it actually gets connected to the network - or could it?
But, even so - that would be a cool feature, wouldn’t it?
There is a program called portal smash that auto connects to wifi networks and it clicks on the captive portals. Portal smash can run on a Raspberry Pi. If I were you I would get a Raspberry Pi and the stuff that you need to use a Pi like a wifi adapter. Then I would make a program that would setup a wifi network when portal smash connected to a wifi network. Then I would connect the Photon to the Pi’s wifi network.
