Release: v1.1.1 — a security fix, and SQLite that works

Upgrade to 1.1.1 if you run the admin. It fixes one security issue and the bugs a fresh SQLite app hit on day one.

Security

The admin’s list pages let a user filter and sort on fields the entity hides. Someone allowed to read users could use that to recover password hashes and MFA secrets, one character at a time. Filters and sorting now only reach fields the admin shows.

Details are in advisory GHSA-g896-jm3g-34h6. Until you can upgrade, limit who may read the users entity.

SQLite

A new app runs on SQLite, and 1.1.0 let it down there:

The users page failed with ambiguous column name: created_at.
No user could be edited in the admin: the form would not submit.
Turning MFA off left it on, and saving a deactivated user in the admin switched them back on.

All fixed. CI now opens every page of a freshly generated app on SQLite, PostgreSQL and MySQL, so this kind of bug fails the build instead of reaching you.

Also

wagoe new switches the admin on, with users already in it. Creating a user no longer ends on a 404.
Deleted users no longer show up in user lists.

Upgrade

curl -fsSL https://get.wagoe.org | bash

Then pin 1.1.1 for every com.wagoe/* dependency. Two things to copy by hand if your app predates this release:

In your own admin/users.edn, type :name and :timezone as :string and the three :notifications-* fields as :boolean. A new app’s copy has them.
A module you scaffolded earlier still reads booleans back as 0/1 on SQLite; convert its boolean fields in →entity, as a newly scaffolded one does.

The full list is in the CHANGELOG.