Authentication Succeeded, but the Login State Was Not Dependable

Simon Willison released datasette-auth-github 1.0 on September 19, 2026. The plugin provides GitHub OAuth login for Datasette, and he uses it on the agent.datasette.io demo site. Its role is to let users enter Datasette with an existing GitHub identity rather than creating a separate username and password system for the site. It acts as a lightweight identity gateway between an external identity provider and the access state carried by later Datasette requests.

The release began with a failure of persistence, not a failure of login. Willison noticed that the plugin had been setting cookies without a Max-Age attribute, so the session expired when the browser session ended. The material specifically notes that this happens fairly often in Mobile Safari and may occur independently of how the user is using the app. From the user’s perspective, a successful GitHub authentication could therefore disappear the next time the browser was opened even though no obvious OAuth error had occurred.

One Cookie Attribute Connects OAuth to Later Requests

GitHub OAuth confirms the user’s identity, but the authentication flow does not end when the callback succeeds. The plugin must also record that confirmation in a state that the browser will send with subsequent requests. When the cookie has no explicit Max-Age, the browser may treat it as belonging only to the current browser session. The way that session ends can then determine whether Datasette still considers the user authenticated.

The focus of issue #80 was to move that lifetime out of an implicit browser decision and into the plugin’s behavior. After the fix, the login cookie lasts 30 days by default and can be configured with login_max_age in seconds. The material gives 86400 seconds as the value for a 24-hour lifetime. The OAuth protocol itself did not become stronger through this change. Instead, session duration became a parameter that an operator can read, configure, and test.

Here, 1.0 Means Dependability

Viewed only through its version number, datasette-auth-github 1.0 could look like a feature leap. The facts in the release are more restrained. The central change is the session-lifetime fix, while the plugin had already existed for some time and had been tested against both Datasette 0.65.x and Datasette 1.0ax. It did not reach 1.0 because it introduced another identity provider, a complex permission model, or a wholly new authentication architecture.

The 1.0 label therefore works more as a maintenance commitment and a compatibility signal. Users are not being promised that every authentication concern has been solved. They are being given a clearer dependency expectation: the plugin has defined session behavior and has coverage across two host-version lines. For teams migrating between, or running alongside, older Datasette releases and 1.0ax, that information is more useful for upgrade planning and regression testing than a generic statement that the plugin supports GitHub login.

Deployment Choices Decide Whether Thirty Days Helps or Exposes

The deployment path itself is lightweight. A team can install the plugin with `datasette install datasette-auth-github`, use GitHub for OAuth sign-in, and restrict access to selected GitHub users, organizations, or teams when needed. The site can continue to allow anonymous access, or it can require every user to authenticate first. That gives the same plugin two different operating roles: a login option in front of a public data site, or an identity gate for an internal or semi-public Datasette deployment.

The 30-day default should not be treated as a universal security baseline. A longer cookie lifetime reduces repeated sign-ins and can be especially convenient on mobile devices, but shared devices, incomplete sign-outs, and stolen cookies all keep an active session available for longer. A technical lead should set login_max_age according to data sensitivity, whether devices are managed by the organization, and who the users are. The default should not be accepted merely because the version number has reached 1.0.

A Stable Release Does Not Close Every Security Boundary

The easiest mistake is to combine session reliability, version compatibility, and authentication security into one conclusion. The material supports a narrower judgment. The missing Max-Age behavior was fixed in issue #80, the default session duration now has an explicit value, and the plugin has a stated testing range covering Datasette 0.65.x and 1.0ax. The material does not say that the plugin has passed an independent security audit, nor does it fully describe behavior for GitHub authorization revocation or stolen-cookie response.

The practical move is to use 1.0 as a dependency-upgrade and regression-testing baseline while checking the organization’s session policy separately. Before deployment, confirm that login_max_age matches internal requirements and decide whether the site should allow anonymous access or require authentication for everyone. Sign-out behavior, authorization revocation, and incident handling after cookie theft should remain explicit verification boundaries. The release is valuable because it makes a hidden browser-lifecycle problem configurable and discussable, not because it makes the security decision on the team’s behalf.