August 5, 2026
A Real-Browser-Only Login Bug, DMX Automation at Church, and Bridging the Gap
A login bug that had been quietly haunting GitLab for a while finally gave up its actual root cause: something real browsers do that no scripted test could ever reproduce. Then a full workday at church rewiring how the lighting, games room, and displays all talk to each other, and dinner with Lisa at her work's Bridging the Gap event to close it out.
The GitLab login bug that only ever broke for real browsers
GitLab, running behind
rust-proxy,
had a login failure that made no sense: it failed every single time in real Chrome and Edge,
desktop and mobile, and worked perfectly every time from a scripted test using the exact same
login. That split is usually the clue that something's happening that only a real browser
does. So instead of guessing, I drove an actual browser through the problem with an automated
testing tool and watched it fail the same way.
I ruled out a long list of reasonable suspects — browser cache, extensions, different
networks and devices, special characters in the password, timing — before the real cause
showed up in a raw capture of the network traffic. I temporarily rerouted the connection so I
could see the exact data going by, then put everything back the way it was. Sitting right
there: the login cookie had been split into four separate pieces instead of one. That's
something real Chrome and Firefox are allowed to do and actually do; the scripted tests don't,
which is exactly why they never reproduced it. GitLab's own server only reads the first piece
off the wire, and the actual login session was sitting in the second one. GitLab never saw a
real session at all, so it rejected the login. I fixed rust-proxy to put those split pieces
back together into one before handing them to GitLab, and confirmed the fix really worked by
watching that same automated browser sail through login, then confirmed it for real logging in
with a security key in one browser and two-factor in another.
That same traffic-capture trick paid off twice more, closing a couple of other real gaps in
how rust-proxy talks to the servers behind it: one kind of request was being forwarded in a
form that happened to work by accident against most servers but got correctly rejected by a
stricter one, so I fixed the format before forwarding it. The visitor's real IP address is now
passed along to every server behind the proxy, instead of every one of them seeing the proxy's
own address as if it made every request itself. And there's now a setting that lets an
operator relax an overly strict cookie setting on a site that needs it, for cases where modern
browsers would otherwise quietly throw the cookie away. All four fixes are tested and pushed.
A church workday automating the lighting and game room
Big day at the church workday: got our control software talking directly to the room's
lighting system, so the presentation software can go back to just running slides instead of
also having to drive the lights by hand. Now the control panel watches what's on screen and
automatically matches the room's lighting to it, with the physical buttons themselves changing
color to show the current lighting mode. A glance at the panel tells you what mode the lights
are in without even looking at the room.
Also fixed the connection between our control software and
Hubitat,
the smart-home system that runs the room's games, the prize counter, and the wall lighting —
that connection had some real problems that got sorted out during the workday. And closed out
a problem left over from the power outage a couple of posts back: a remote-control hub had
broken during that outage and hadn't worked right since, which meant the projector and the
stage screens couldn't be turned on and off automatically. That's fixed now too, so pressing
a single button turns the projector and stage screens on and off again.