ulsklyc/yuvomi v2.69.1

on GitHub

Security

• A member can no longer decide where another person's first single sign-on ends up. The first
  time someone signs in with SSO, Yuvomi looks for their existing account by the email address the
  identity provider confirms. Members can edit the email address on their own profile, and that was
  enough to send another household member's first SSO sign-in into a new, empty account instead of
  the one prepared for them, or into the member's own account. OIDC_ALLOW_SIGNUP=false did not
  prevent the second case. Linking by email address now only happens for accounts whose address
  nobody but an admin can have set: accounts created with "SSO sign-in only" and admin accounts. When
  the address is on more than one account, the sign-in is refused with a message saying so, instead
  of quietly creating another account. Guests of shared expenses no longer take part in this at all.
  Members also can no longer give their own profile, their own contact or a shared-expense guest an
  email address that already belongs to another account; admins still can, for example for a shared
  family mailbox. Accounts that are already linked to SSO are not affected.

  What admins need to do: a member whose account has a password and is not yet linked to SSO is
  no longer linked by email address. Their first SSO sign-in is refused with a message that asks
  them to sign in with their password and use "Link SSO account" under Settings → Account →
  Single sign-on; alternatively, switch the account to "SSO sign-in only" under Settings →
  Administration → Family, and their next SSO sign-in links it. If you have set
  AUTH_ALLOW_PASSWORD_LOGIN=false, those members cannot sign in with a password, so switch their
  accounts to "SSO sign-in only". An address that is on several accounts has to be left on one of
  them before that person can sign in. Refused sign-ins are written to the server log with the
  account ids involved. It is worth checking once under Settings → Administration → Family which
  member contacts carry another person's email address, and whether an unexpected account (for
  example a name with -1 at the end) was created by an SSO sign-in.

• Only admins can manage CardDAV accounts now, as the settings page already promised. The
  contact sync page was shown to admins only, but the server checked nothing beyond access to the
  contacts module, which members have by default. Any member, and any API token with
  contacts:write, could list the household's CardDAV accounts with their server address and
  username, add or remove accounts, switch address books on and off, and change an account's server
  address while its stored password was kept, so that the next connection test or sync sent the
  household's CardDAV credentials to that server. Every route under /api/v1/contacts/cardav now
  requires an admin; members get 403. An API token needs an admin as its subject and, as before,
  the contacts scope. Members keep reading and editing contacts as before, and the background sync
  keeps running.

• A CardDAV account moved to another server or username needs its password again. Leaving the
  password empty when editing an account still keeps the stored one, but only while the server
  (scheme, host and port) and the username stay the same. Otherwise the change is refused with
  400 and the error code password_required, and nothing is saved. A different path on the same
  server keeps working without the password.