038e09b202
specially when running a multi-arch cluster and HA with poor observability. a `time.Duration` was being casted to an `int` (because I clearly have no clue of what I'm doing). All is well on 64-bit processors, but 32-bit processors choke on the very long micro-second precision int, overflow, and turn `7d`, around `604800` seconds into `-114753536` seconds, which the browser happily (and correctly) turns into a cookie sent to /dev/null. lol. |
||
---|---|---|
cmd | ||
internal | ||
.editorconfig | ||
.gitignore | ||
config.template.yaml | ||
go.mod | ||
go.sum | ||
LICENSE.txt | ||
main.go | ||
README.md | ||
schema.sql |
la puerta de mi casa
A ridiculously elaborate rubegoldbergian contraption to exchange my guests' biometric data for my front door going bzzzz, built with go, css, html and javascript.
This project is:
- highly insecure: you should not run this at home,
- very alpha: to put it mildly,
- poorly tested by my guests and myself, so barely—if at all, and
- truly magical to see in action, when it does work.
Web App
This is what my guests see. It's basically a login page where they enter credentials, and then a big button to open the door. My guests are required to authenticate with a passkeys before opening the door, usually backed by a yubikey, TouchID or whatever android does.
A very simple admin page allows me to manage guests and see the entry log. Built with pochjs (plain-old css, html and js).
API
The API runs on my homelab, serves the web app and interacts with my front door's buzzer. It's built with go and backed by SQLite.
Adapters
Since the buzzer electrical setup is still not something i completely understand, I went around the issue by connecting the buzzer's power supply to a "smart" plug. Originally built it to control a wemo mini smart plug, but have since switched into using a hue one for no good reason other than the wemo's API is annoying.
CLI
There's a small CLI tool to start the API, setup and test the Hue connection, and to add users (helpful during bootstrap).