Tokens were HMAC(serverId, credentials + client IP). serverId is public (mDNS, MQTT, /loginContext), so anyone who saw a token could test PIN guesses offline. The key is now 32 random bytes made on first boot in their own NVS namespace, which no settings save clears and no backup holds. It is made before WiFi starts, from the bootloader's entropy source. Tokens are compared with tokenMatches, which takes the same time whatever the guess, on the apikey header, the socket upgrade and /login. createAPIToken never freed its mbedtls context, so every token it made leaked: 563 bytes per login on the device, until it ran out of memory after about 150 logins. It now frees it: 0 bytes over 500 logins. Every token made before the upgrade is refused once. The web UI asks for login again, and Home Assistant 3.0 logs in again by itself. Closes #80 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| conftest.py | ||
| proto_client.py | ||
| README.md | ||
| test_auth.py | ||
| test_commands.py | ||
| test_edits.py | ||
| test_messages.py | ||
| test_settings.py | ||
| test_survival.py | ||
| test_sync.py | ||
e2e suite
Runs against a real device on your network, by hand, never in CI. It checks socket protocol 2 (PROTOCOL.md) and that the device survives the loads that used to run its heap out.
~/.platformio/penv/Scripts/uv run --no-project --with pytest -- pytest test/e2e --device 192.168.1.120
| Option | Use |
|---|---|
--device |
the device's address (required) |
--password, --username / --pin |
the credentials of a Secured device |
--radio --shade <id> |
also send real commands: that shade moves a little and back |
--edit |
also add a room and delete it again |
--reboot |
also reboot the device and wait for it to come back |
--lockout |
on a Secured device, also fail /login until this PC is refused, then wait out the 30 s lockout |
--record |
save hello, the sync and the schema to test/fixtures/proto2/, for the web UI and Home Assistant tests |
A plain run sends nothing on air, changes no setting (it saves only values the device already has) and doesn't reboot the device. The command tests send ops that are refused before they reach the radio, and one setPositions that sets a shade to the position the sync gave: that drops the fraction of a percent the shade's believed position may have had. The edit tests send edits that are refused, and one shade sort order set to the order it has, which saves the shades again unchanged. The settings tests send saves that are refused, and one that saves the NTP server and time zone the device already has. The frequency scan test pauses the radio's sending for a second or two, as a scan does. It does fill every socket slot for a few seconds, and replays a page load.
The web UI holds one of the device's 5 socket slots for each open tab. The tests that fill every slot skip while one is taken, so close the UI's tabs before a run.
The tests run in whatever security mode the device is in; the suite never changes it. To test both modes, run the suite once in each.