认证成功，却没有留下可依赖的登录状态

Simon Willison于2026年9月19日发布datasette-auth-github 1.0。这是一个为Datasette提供GitHub OAuth登录的插件，作者在agent.datasette.io演示站上使用它，解决的是让用户借助已有的GitHub身份进入Datasette，而不是为站点另建一套账号和密码体系。插件可以作为一个轻量的身份入口，连接外部身份提供方与Datasette后续请求之间的访问状态。

这次发布的起点不是一次登录失败，而是登录状态没有稳定地持续下去。Willison发现，插件此前写入Cookie时没有设置Max-Age，因此会话会在浏览器会话结束时失效。材料特别提到Mobile Safari经常出现这种情况，而且不一定与用户如何使用应用有关。对用户而言，结果是刚刚完成的GitHub认证可能在下一次打开浏览器后消失，系统却没有发生明显的OAuth错误。

一个Cookie属性，连接了OAuth与后续请求

GitHub OAuth负责确认身份，但认证流程并不在回调成功的那一刻结束。插件还需要把这次确认写成浏览器后续请求能够继续携带的状态。如果Cookie没有明确的Max-Age，浏览器就可能把它当作只属于当前浏览器会话的状态。浏览器如何结束这个会话，便会直接影响Datasette是否还把用户视为已认证。

#80修复的重点，就是把这个原本交给浏览器自行决定的生命周期写进插件行为。修复后，登录Cookie默认有效30天，也可以通过login_max_age按秒配置。材料给出的配置例子是，24小时对应86400秒。这里的变化并不在于OAuth协议本身变得更强，而在于会话持续时间从一个隐含的浏览器行为，变成了部署者能够阅读、配置和测试的参数。

1.0在这里代表的是可依赖性

如果只看版本号，datasette-auth-github 1.0很容易被理解成一次功能跃迁。材料给出的事实却更克制：这次核心变化是修复会话持续时间问题，而插件此前已经运行了一段时间，并且针对Datasette 0.65.x和Datasette 1.0ax进行了测试。它没有因为新增另一种身份提供方、复杂权限模型或全新的认证架构才进入1.0。

因此，1.0在这里更像是一个维护承诺和兼容性信号。使用者得到的不是“所有认证问题都已解决”的保证，而是一个更清楚的依赖预期：插件有明确的会话行为，并覆盖两个宿主版本线。对需要在旧版Datasette和1.0ax之间迁移或并行运行的团队来说，这种信息比单纯写着“支持GitHub登录”更能帮助他们安排升级和回归测试。

部署选择决定30天是便利还是暴露面

部署路径本身很轻量。团队可以使用`datasette install datasette-auth-github`安装插件，通过GitHub完成OAuth登录，并按需要限制指定GitHub用户、组织或团队。站点还可以继续允许匿名用户访问，或者配置为所有用户必须先登录。这样一来，同一个插件既能放在公开数据站点前面，也能作为内部或半公开Datasette部署的身份门槛。

但默认30天不应被直接当作安全基线。较长的Cookie有效期可以减少重复登录，对移动端用户尤其方便，可是共享设备、未彻底退出的浏览器以及Cookie被窃取时，都会让有效会话保持更久。技术负责人需要根据数据敏感度、设备是否受组织管理以及用户群体来设置login_max_age，而不是因为版本号变成1.0就接受默认值。

稳定发布不等于安全边界已经闭合

这次升级最容易被过度解读的地方，是把会话可靠性、版本兼容性和认证安全混成一个结论。材料支持的判断是，缺少Max-Age的问题已经在#80中修复，默认会话时间有了明确值，插件也列出了对Datasette 0.65.x与1.0ax的测试范围。材料并没有说明插件经过独立安全审计，也没有给出GitHub授权撤销、被盗Cookie处置等问题的完整行为说明。

因此，适合的工程动作是把1.0作为依赖升级和回归测试的基线，同时单独检查组织真正关心的会话策略。部署前应确认login_max_age是否符合内部要求，确认站点究竟允许匿名访问还是要求全员登录，并把退出登录、授权撤销和Cookie泄露后的应急处置列为待验证边界。这个版本值得采用的理由，是它让一个隐蔽的浏览器生命周期问题变得可配置、可讨论，而不是替团队替代安全决策。