a8d18d8812
safari complains about bare async calls not being triggered by user action after a click allow admins to have multiple open sessions general webapp tweaks to background colors and button widths |
||
|---|---|---|
| cmd | ||
| internal | ||
| .editorconfig | ||
| .gitignore | ||
| .tool-versions | ||
| 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).