New Ory Agent Security is now live! Claim your complimentary test drive. Get Started!

Skip to main content

v26.4.15

v26.4.15​

A failed SCIM group PATCH now takes back the changes it had already written​

A PATCH on /Groups/{id} that fails partway now takes back the name and membership changes it had already written, instead of leaving them applied. Until now each operation was written as it was applied, so a failure after an earlier write kept that write: a request renaming a group and changing its membership could answer an error with the new name stored and the membership untouched. The identity provider recorded the sync as failed while Ory kept half of it, and the two drifted apart. This affected every group PATCH shape — a pathless add or replace carrying both displayName and members, a members path operation, and any request whose later operation failed after an earlier one succeeded.

The recovery is limited, and the limits matter before you rely on it:

  • Changes another request makes to the same group at the same time are kept, with three exceptions. The name is put back only while the group is exactly as the failed request wrote it, so after a concurrent change the failed request's rename stays in place. A member the failed request added is removed unless another PATCH has added it since; a PUT that found the member already present does not count. A member the failed request removed is added back even if another request removed it meanwhile. And when two concurrent PATCH requests add the same member and both fail, the member stays in the group.
  • It covers up to 10,000 changed memberships in one request. A larger change is taken back only in part.
  • Events already delivered for the operations that did succeed are not withdrawn, so a webhook consumer can still receive a group.updated or group.user_added for a request that then failed.

Reconcile against the group itself rather than treating each event as final.

Admin Portal admins sign in again once after upgrading​

The Admin Portal no longer uses NextAuth.js. Its session cookie keeps the same name and 30-day lifetime but has a new format, so every admin is signed out once when you upgrade and signs in again as before.

Credentials, magic links and SSO sign-in work as before with the same NEXTAUTH_URL, NEXTAUTH_SECRET, NEXTAUTH_ACL and NEXTAUTH_ADMIN_CREDENTIALS variables. Magic links sent before the upgrade still work, and the Admin Portal SSO connection keeps its callback URL.

Identity Federation apps accept more than one ACS URL​

An Identity Federation app now takes extra Assertion Consumer Service endpoints in additionalAcsUrls, alongside the acsUrl it already had. Use it when a service provider owns several ACS endpoints under one entity ID, such as an SAP Cloud Identity Services tenant reachable on both the accounts.ondemand.com and accounts.cloud.sap superdomains.

acsUrl and additionalAcsUrls together form an allow-list, matched exactly. A sign-in request that names an ACS URL is answered at that URL only if the URL is on the allow-list. A request that names none, and an IdP-initiated sign-in, is answered at acsUrl.

acsUrl keeps its meaning and is not deprecated. An app whose service provider receives assertions at a single endpoint needs no change, and leaving additionalAcsUrls empty is the same as not setting it.

Polis no longer logs expected duplicate-key failures as query errors​

With a SQL database, Polis logged a query failed error for every insert that found its record already there, such as an INSERT ... Duplicate entry on MySQL. Those failures are how Polis detects an existing record, not faults, but they filled logs and hid real errors. Polis now leaves unique-key violations out of its query error log and logs every other failed query as before.