The lock screen a reload could skip

This one was humbling. The Control Plane had an idle lock: after fifteen quiet minutes it covered the screen and asked for your password. It looked secure. It wasn't, because the whole thing lived in the browser. The session on the server stayed valid, so reloading the page skipped the lock entirely.

Expiry has to happen where the session is

Now an idle session ends on the server. Each Control Plane request records when the session was last active. When a request arrives after too long a gap, the session is deleted and the cookie with it, so a reload lands on the sign-in page like it should. The default is two hours, and a site can change it with session.idle_minutes in config/nibble.yml.

Asking the time mustn't reset the clock

The browser still counts down, so it can warn you a minute before. To stay in step with the server it asks how long is left. The first thing to get right: that question doesn't count as activity. Otherwise an open tab would keep its own session alive forever by checking on it.

Signing back in without losing the page

When a session does end, you might be halfway through writing something. So instead of throwing you out to the sign-in page, a dialog asks for your password, and your two-factor code if you use one, and signs you back in right there. The page underneath keeps everything you'd typed. That meant teaching the sign-in endpoints to answer in JSON as well as with redirects.

How I tested it

Unit tests prove the rules. To see it for real, I set the idle time to two minutes, signed in, waited for the warning, waited for the dialog, and then reloaded. Sign-in page. Then I signed in through the dialog instead and checked the page was still the one I'd left.

The lesson: a security feature that only exists in the browser is a UI feature.