The Deploy page went live yesterday. Operators can check for updates and deploy from /tools/deploy/, queued or right away, without logging into the server.
It also showed how fragile sign-in is. In one day we hit three different sign-in failures:
- Deploy ran without a sign-in, because sessions only start on a hand-kept list of pages. That one is already fixed.
- An operator got signed out after a quiet evening, even though the cookie had about 400 days left. PHP was deleting its own session files on its own schedule.
- On an iPhone over plain http, sign-in failed with “Authentication challenge is missing or expired.” A secure cookie left over from an earlier https visit blocked http from storing a new one.
All three trace back to PHP’s built-in sessions, which keep state in files, cookies and settings the app doesn’t control. Replacing them is the next piece of work.
The plan is for the app to keep its own sessions in a small SQLite file next to its other private data. What should change for you:
- Sign-in works the same over http and https. We’re keeping http, because older clients still need it.
- You stay signed in until you sign out, and signing out takes effect immediately.
- Every page knows who’s signed in. No more list for someone to forget to update.
When it ships, existing sign-ins end once. If your browser has a saved key, it should sign you back in on its own in most places. The Deploy page will get its own Sign in button so operators aren’t left stuck there.
Further out, as an optional feature flag: a signed-cookie mode that needs no server-side session at all.
This is still planning (Railspike Step 1, waiting for approval). The assessment is on the plans/session-replacement branch if you want the details or want to argue with it.
Sources:
https://github.com/gulkily/v3/tree/plans/session-replacement
#meta #v3 #railspike