Add Web Workflow

[tannewt]

Let's add a way to work with CircuitPython over the (local) web!

How it should work

1. First, load http://circuitpython.local:7676 in a web browser. This uses mDNS to do a local domain lookup.
2. All CircuitPython devices on the network will reply with their IP. The first will win.
3. The browser will then request / from that IP.
4. The running webserver will see the circuitpython.local host and will return with a 302 redirect to the device's specific domain which will be cpy-000000.local where 000000 is the last three bytes of the mac address. (mDNS is also used for the cpy-000000.local lookup but only on device will reply.)
5. When the device gets a / request for its unique hostname it will return a small HTML page that loads Javascript from code.circuitpython.org or somewhere else that turns the page into a full editor.
6. The editor can use a REST API or form-compatible upload to read and write files. The serial connection will be available over an insecure "websocket".
7. Each device will also provide a /peers endpoint that will cause it to do a service discovery mDNS request that finds all other CircuitPython devices on the network. The web editor can then provide links to other devices directly.

Getting on WiFi

This method doesn't address how a device gets on the network to begin with. The simplest way is by editing WiFi config settings over USB mass storage. For devices without USB, a webserial based webpage can be provided to write credentials. See how wippersnapper does it.

TODO

• Check in mDNS support.
• Add supervisor.disable_web_workflow() to prevent WiFi from running outside of user code. Depends on CIRCUITPY_WIFI_SSID.
• Add auto connect to configured WiFi. wifi.radio.connect() could be modified to save credentials.
• Stop resetting WiFi completely between VM reloads. We want to keep the serial connection alive.
• Create internal HTTP server to:
  • Redirect circuitpython.local requests to its unique hostname.
  • Reject requests with an Origin that isn't in an allowlist so regular insecure pages cannot access it.
  • Serve web editor stub at /
  • Serve /peers with other device info.
  • Provide REST API for reading and writing files.
• Connect the serial input/output to a socket. Likely 23 to match telnet. Should be usable through an insecure websocket as well.

[ATMakersBill]

Given that these devices can (in some cases must) have their SSID/KEY set and perhaps an IP, I think it would be good to add a way to set the hostname. In the secrets.py file, an optional parameter named mDNS name or hostname or the like would be super helpful.

If that isn't found, then the circuitpython.local would be the default. But this allows a longer-term solution when there are > 1 CP device on the network.

Also, why are we using port 7676? That makes the assumption that Windows Firewall won't care (for outbound requests, that's probably safe), but is there a driving requirement for this?

There are multiple ways to manage getting the name on the network. mDNS is one (UDP multicast over port 5353), but most DHCP servers will also accept hostnames set in the DHCP client request (I believe it's option 81). My router at home allows you to name servers and "pin" the name/IP lease so that the MAC will always get the same values. If we are supporting DHCP, sending the hostname would be helpful (and having it in the secrets.py file would make it easy).

[tannewt]

Given that these devices can (in some cases must) have their SSID/KEY set and perhaps an IP, I think it would be good to add a way to set the hostname. In the secrets.py file, an optional parameter named mDNS name or hostname or the like would be super helpful.

This is possible with wifi.radio.hostname already. The mDNS hostname currently defaults to cpy-###### but we should probably have them align.

#6175 allows for changing the unique name through mdns.Server(wifi.radio).hostname.

If that isn't found, then the circuitpython.local would be the default. But this allows a longer-term solution when there are > 1 CP device on the network.

The proposal above does handle >1 cp devices on the network because they respond to circuitpython.local and cpy-######.local. The latter would be unique.

Also, why are we using port 7676? That makes the assumption that Windows Firewall won't care (for outbound requests, that's probably safe), but is there a driving requirement for this?

We were just brainstorming a port number on Discord. I'm open to suggestions. We wanted to avoid 80 because the user may want to use it for their own code.

There are multiple ways to manage getting the name on the network. mDNS is one (UDP multicast over port 5353), but most DHCP servers will also accept hostnames set in the DHCP client request (I believe it's option 81). My router at home allows you to name servers and "pin" the name/IP lease so that the MAC will always get the same values. If we are supporting DHCP, sending the hostname would be helpful (and having it in the secrets.py file would make it easy).

I believe wifi.radio.hostname is already used for DHCP. It'd be good to align this with mDNS as I said above. I do think that having a selection screen will make it much easier to pick the device you want rather than needing to understand the hostname itself.

[anecdata]

wifi.radio.hostname does make it to the router via DHCP.

The ability to "pin" or reserve DHCP MAC-to-IPv4 address mappings is a convenience offered by most routers, I'm not aware of any standards that cover it.

As I read this, hostname and mDNS hostname may get aligned, but since wifi and mdns would be separate imports, it should hopefully support use cases where a wifi.radio.hostname is desired but not an mDNS hostname.

[prplz]

If you're making wifi persistent, how about a telnet server for the repl too?

[anecdata]

Stop resetting WiFi completely between VM reloads. We want to keep the serial connection alive.

This is desirable for web workflow. However, users are currently in full control of starting and stopping a Station and connecting to an AP, starting and stopping an AP, starting and stopping wifi, etc. There should be a mechanism where user code still retains full control of whether / when / how the device interacts with a wifi network, during code execution and across reloads and resets. In other words, it should still be possible for a CircuitPython device to reload or reset into a mode where it is not interacting with wifi, but code can later connect or do other wifi actions (presumably including mDNS or web workflow).

[tannewt]

If you're making wifi persistent, how about a telnet server for the repl too?

Yup! I mention something similar in #6 but forgot to add it to the TODO list.

This is desirable for web workflow. However, users are currently in full control of starting and stopping a Station and connecting to an AP, starting and stopping an AP, starting and stopping wifi, etc.

Agreed! I'd probably add a supervisor.disable_web_workflow() just like supervisor.disable_ble_workflow(). That'd move it back to the current API I think.

[FoamyGuy]

This is such a neat idea! Looking over the tasks you've outlined with an eye toward finding some part that I might be capable of helping with, I'm curious if the internal HTTP server that you mentioned is something that will get written with python code? or it's internal to the core and thus written in C?

[KTibow]

Hype! This probably won't be useful to anyone, but here's my OTA solution I built for my project. It just fetches from GitHub.