The first Windows install reached the setup screen, typed an installation code, and was told the session had expired. There was no session. The code had been minted on a different head office, and the server said so - 401 bad_token, "That installation code is not valid. Ask for a new one." - and the client threw the message away, because it mapped every 401 to the string "session expired". A 401 on a call that carried a session is a session problem. A 401 on a call that carried none is about the request, and the server's message is the answer. The client now tells them apart by whether it sent a token. Two tests, one for each side of the rule. Also: a launcher for pointing a Windows PC at a head office on the LAN, with the two settings that needs and a comment saying why neither is acceptable outside a demo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
22 lines
1007 B
Batchfile
22 lines
1007 B
Batchfile
@echo off
|
|
rem Start Behavision against a head office running on another PC on this LAN,
|
|
rem instead of the production server it uses by default.
|
|
rem
|
|
rem For demos and pilots only. Two things are deliberately weaker than
|
|
rem production and both are named here so nobody copies this into a shop:
|
|
rem
|
|
rem - head office over plain http, not https
|
|
rem - the message broker over plain tcp. The app REFUSES plaintext MQTT to
|
|
rem any address that is not its own machine, by design - the payloads are
|
|
rem customer visit records - so the second line below is the documented
|
|
rem escape hatch and must not be set anywhere that is not a demo.
|
|
rem
|
|
rem Edit the address to the PC running head office, then double-click this
|
|
rem instead of Behavision.exe. Everything else - the installation code, the
|
|
rem sign-in, the cameras - works exactly as INSTALL.txt describes.
|
|
|
|
set BEHAVISION_CLOUD=http://192.168.1.117:8088
|
|
set BEHAVISION_ALLOW_PLAINTEXT_MQTT=1
|
|
|
|
start "" "%~dp0Behavision.exe"
|