so like, all the staff at the kids' school have google-workspace-managed gmail addresses at the school's domain name. i can tell haproxy to let them "sign in with google" (oauth2) and thereafter they may access staff-only pages without maintaining any database or user list on my server

i can configure haproxy to do the denying, or have it set the visitor's email address into the headers that get proxied back to the webserver. no need for the webserver to know how to oauth

this counts as december adventure

with a short python cgi script i'm close to having oauth2 working
(via google first, then more)

oauth2 gives a signed jwt
haproxy can validate and pull data out of that for use as acl material

this means i can say "only people who have a google workspace account at the kids' school may request these urls from my static site"

or

"only my local fedi tl may post changes to this wiki"

with no server side database or redis or anything 😎

if it works

december adventuring

work in wip progress: i have a short python cgi that implements enough of OIDC (Open ID Connect, based on OAuth2) that you can click a link on my site to "sign in with google"

i receive what you told google your name and email address is, signed by google

i stick that into your browser cookies so i don't have to store it

next step: get haproxy to parse and verify it to let you see the secret pages, if i like you

maybe replace with my own, shorter, signed cookie

oh my gosh i am logged in -- securely attesting my identity to my mostly static website! the only moving parts on my vps are a little script that stuffs the key into a cookie and some configuration in haproxy to make it inspect and verify it

the list of allowed users amounts to a text file, no database or session storage on the server. all i will have to do to "give you an account" so that you can access the secrets and writeable parts is put your google email address in a text file

next steps:

• as is, this doesn't let google track you as you click around my site. it only knows you granted permission to my site to see your name and e-mail. but i want to expand this to work on any oidc provider that i decide to trust including your or my jank homebrew ones because fuck google

• stuffing the whole signed jwt into a cookie is kinda heavy. will probably replace that with my own smaller one that doesn't encode anything i don't need to control access

why don't more sites do it like this? i think because

• wow oauth and oidc are tedious
• google and facebook and apple and microsoft and auth0 by okta would all prefer that you use code that they control, or pay for their service instead of rolling your own
• why would you go to the effort to avoid storing session data on your server when you have this huge database right here to collect as much customer info as possible to sell to the highest bidder

yay i'm gonna implement an OpenID Connect client so you can log into my website with any of the many OpenID Connect Providers out there and i don't have to keep a list of usernames and passwords!

except i hate google, reddit, github, twitter, facebook, amazon, paypal, and apple so,

you can log into my website with your existing account on...
salesforce,
auth0, or
yahoo

so convenient! ✨

back to the tech wip: currently figuring out how to use the state parameter to stop csrf attacks, without storing stuff on the backend to verify it hasn't changed, also without accidentally inviting tampering and replay attacks

i think i can just stick a random number in there, "sign" it with an hmac, store the hmac in cookies, check that against state when it comes back

"don't roll your own crypto" but ya'll didn't roll it for me so guess what

(cue ridin' by chamillionaire)

december adventure, wip:

• learned about blake2, used it for the signed state parameter, seems to work well
• got the secrets out of my script so i can commit it to version control and share it
• got a couple of the possible error messages to be less ugly
• tightened up the security params of the cookies i'm using
• deleted the state cookie as soon as we're done using it

to do:

• use a small signed data blob in cookies not the big id token google hands us
• tidy up my use of pyjwt
• stop hardcoding, and instead properly cache, and refresh, oidc discovery documents and providers' certs
• see how hard it is to enable more oidc providers than google (ideally just, register with them and add their discovery document url?)
• something neat on the frontend so you can actually tell that this stuff is working 😅
• blog about it

i must be getting deep into it, just learned that this issue i'm struggling with is not my own fuckup, it's a bug in haproxy that's causing responses to fail in glitchy ways when a jwt signature doesn't validate

haproxy devs know about it and fixed it but the patch hasn't been backported to various versions yet

https://github.com/haproxy/haproxy/commit/46b1fec0e9a6afe2c12fd4dff7c8a0d788aa6dd4

my workaround for now is going to be only attempt jwt validation when the keys match

random achievement: got my travel router set up as a proper travel router

updated openwrt, installed travelmate. now my partner and i can use our phones and laptops together on the hotel wireless without paying exorbitant additional-device fees (not that we ever did that) and have high-quality file transfers between our own devices

there's not enough room on it to install tailscale so maybe it's time to more seriously consider zerotier or a manual wireguard setup

my workaround for the haproxy issue upthread 🧵☝️ doesn't work great because google and probably other identity providers rotate their certificates frequently

instead of building a giant contraption to keep haproxy config updated with multiple configuration lines for every cert i might need, i'm trying to do what people used to do before haproxy grew a jwt_verify builtin: do it with a lua plugin 😎

part of me gets excited about it like  what other clever hacks could i do with a lil lua plugin to haproxy!

openresty pretty famously implements an entire web platform in what was probably intended to be a little lua extension for nginx

then on top of that web frameworks like lapis exist which let you code your web thing in lua, moonscript (kinda coffeescriptish) or fennel (lisp!)

https://openresty.org/en/
https://leafo.net/lapis/
https://fennel-lang.org/

a high quality mufo recently mentioned caddy so i looked and gosh

caddy (w/plugins) has a lot of things i stalled out trying to make happen with haproxy+lua+lighttpd:

• jwt, oidc, client cert auth
• webdav
• fastcgi
• dispatch by sni
• a static fileserver
• precompressed files
• if-unmodified-since (with PUT?)

but i agree that the glossy marketing website is sus. some exec is going to spring a trap as soon as it's popular

caddy is golang which i've been stubbornly avoiding learning for as long as it has existed. i would prefer software that stands between my computer and the nasty internet to be written in rust...

but, as much as i dislike golang i think i dislike c and c++ even more

haproxy and nginx are both written in c, and i've segfaulted both with mere configuration file mistakes which makes me super nervous

so maybe i will try caddy next

oof, caddy with my selected modules eats 14% of my weak little vps's half-gig of ram. that's even chonkier than nodejs who i have already been complaining about and trying to expunge

but maybe that's fine for now since it's fast and nice and has lots of features i like

caddy's webdav + static fileserver works pretty well except that it has the same flaw nginx does: GET requests understand and behave correctly in the presence of HTTP conditional request headers like If-Match or If-Unmodified-Since, while PUT requests silently ignore those headers. which will cause lost data with concurrent edits

nbd i'll just write my own simple tiny PUT handler as a fastcgi i guess since that's all i wanted out of webdav really

recently learned that debian has a software repo explicitly for installing recent versions of haproxy. so i could get one where the bug mentioned upthread is fixed

burned up a ridiculous amount of time troubleshooting a "file not found" error in my config, when i should have stopped relying on docs and read the source. because the haproxy docs and the error message is mistaken:

(contd)

jwt_verify(alg, key): ... the key parameter should either hold a secret or a path to a public certificate

no, it wants the public key extracted from a certificate, not the certificate itself. gotta do this:

openssl x509 -noout -pubkey < cert.pem > pubkey.pem

also you can only have one key per file so it's on you to match the id in the jwt to the file holding the corresponding key

today i learned that if you are reverse-proxying :80 and :443 with PROXY protocol to a caddy set up like this...

then, in addition to your https site definitions, you also have to toss this line in there to make proxy_protocol apply to the automatic http->https redirect that caddy sets up

https://caddyserver.com/docs/caddyfile/options#:~:text=unless%20you%20explicitly%20declare

but with this figured out, i now have an ipv6 vm that can still serve up its websites to people stuck on ipv4-only networks! without paying for an ipv4 address allocation! 🥳

next, to see if a prosody xmpp server and a coturn turn/stun server will work just as happily as the webserver does within this setup

🤔 turn and stun are mechanisms to help ipv4 clients behind nats talk to each other directly, or failing that, proxy their traffic to each other

nats are pretty much only for ipv4 clients. if they have an ipv6 address is probably isn't nat'd

so it probably doesn't make sense to imagine how to run a stun/turn server on an ipv6-only vm

the appropriate place for it to live is probably alongside the sniproxy doing ip4->ip6 reverse proxying

possible workarounds:

• put all the clients i care about doing video calls with (my immediate family) on tailscale, which also performs the function of nat traversal
• talk to my provider about installing coturn on the ipv4 proxy box? but the cost in bandwidth and maintenance might be too high, especially if i'm the only customer using it
• maybe stun/turn as-a-service exists?
• admit defeat and just pay $1/mo for an ipv4 address

today i learned firefox's network.dns.preferIPv6 is false by default :C

🤔 that setting fixes mine but how can i trick other people's browsers on dual-stack networks into preferring ipv6, instead of unnecessarily using the shared ipv4->v6 proxy my host generously provides?

first software deployed to the beefy new vps is TiddlyPWA, and it is pretty great, and easier to install than i thought it would be. going to use it as a lab notebook and planner for the rest of the things i want to deploy

i was originally reluctant to use it because it doesn't seem like it would handle multiplayer -- multiple people working on the same page at the same time -- very well. but for now i'm the only user and it's great

a small tiddlypwa continues to work great, even on my mobile device on random networks on the other side of the planet. a far better experience than my big tiddlywiki5 instance.

deno (and node) are both chunkier than i'd like but the utility tiddlypwa provides outweighs that. a problem for later.

try it out! support the author!

setting StateDirectory=foo in a systemd unit makes it create the directory /var/lib/foo and set $STATE_DIRECTORY to that
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=

$STATE_DIRECTORY will expand in your Exec= declaration but not in e.g. Environment=

so i can't say

instead i have to
Exec=env DB_FILENAME=${STATE_DIRECTORY}/database.sqlite3 /usr/bin/command

is there a prettier way?

is there a prettier way?

there is!

systemd.unit "specifiers"