Yuvomi

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.