For the full list of changes, check out the Webiny 5.38.1external link release on GitHub.
SECURITY PATCH
This release contains a low severity security patch!

Security
anchor

withoutAuthorizationExecution Context Scoping (#3714external link)
anchor

Problem Description
anchor

One of our community members discovered an interesting issue when running GraphQL queries which contain multiple selections. When GraphQL is executing a query, multiple selection paths are executed in parallel, and if one of those resolvers runs into a security.withoutAuthorization() method call, the authorization will also be disabled for all parallel executions, for the duration of the provided callback. This means that the data fetching logic is affected, and the resolver might return data which should otherwise not be returned.

When Does This Happen?
anchor

You will not see this in our Admin app queries, because we never run queries with multiple root level selections. However, if you run a manual query, using any GraphQL client, our API Playground, you will be able to construct a query which exposes this issue. For security reasons, we will not show examples of queries which can reproduce the issue.

How Serious Is This?
anchor

From your system security standpoint, this is a low severity issue, because this can only be exploited if you already are a system user, meaning you have valid credentials, and can log in. This cannot be exploited by public (anonymous) users without credentials.

The Solution
anchor

The solution uses the async context trackingexternal link feature of Nodejs. This makes it possible for us to track the state of authorization on the execution context level, and not the entire request. So now, even if one part of the code execution temporarily disables authorization, all parallel execution paths would still have the authorization enabled.

Removed Methods
anchor

To make the patch described above work reliably, we had to finally remove methods enableAuthorization() and disableAuthorization() from the Security app. These methods have long been deprecated, since the introduction of withoutAuthorization() method, so this should not come as a surprise.

Still, if your plugins used these two deprecated methods, you will be forced to upgrade the usage. Here’s what you’ll need to do:

Old Usage

This same code will now look like this:

New Usage

Headless CMS
anchor

Custom DateTime and Identity Input (#3718external link)
anchor

This is an advanced feature, only available by directly calling the GraphQL API mutations, for users who want to import data from their existing system and retain the DateTime and Identity data.

With this release, our users can set their own custom DateTime values to the createdOn, savedOn and publishedOn fields. If the values are not sent to the GraphQL API, the code falls back to the already existing functionality.

They can also set their own custom Identity values to the createdBy, modifiedBy and ownedBy fields. If the values are not sent to the GraphQL API, the code falls back to the default functionality.

Setting your own custom DateTime and Identity values can be done when creating an entry, creating a new revision of the entry or updating the entry.

Skipping the Update ofsavedOnandpublishedOnFields When Publishing an Entry (#3718external link)
anchor

This is an advanced feature, only available by directly calling the GraphQL API mutations.

With this release, our users can choose to skip the update of the savedOn and publishedOn fields when publishing an entry. This can be done by setting the updateSavedOn and updatePublishedOn argument to false when calling the publish mutation.

By default, the system updates those fields when publishing an entry.

File Manager
anchor

Bulk Edit File Manager Extension Fields (#3715external link)
anchor

If you are using custom file fields in the File Manager, you will now be able to bulk edit them, using this new early preview feature. To enable bulk editing of your custom file fields, you need to se a bulkEdit: true property:

Once you deploy your API, the File Manager will auto-detect your bulk-editable fields. Once you select multiple files, a new action will appear in the top toolbar, which will bring up the following dialog:

Bulk Edit DialogBulk Edit Dialog
(click to enlarge)

Custom DateTime and Identity Input (#3718external link)
anchor

This is an advanced feature, only available by directly calling the GraphQL API mutations, for users who want to import data from their existing system and retain the DateTime and Identity data.

Because our File Manager is built on top the Headless CMS code, it also can use the same custom DateTime and Identity input functionality.

The main difference here is that the File Manager does not have the publishedOn and ownedBy fields. The reason behind that is that the File Manager does not have the concept of revisions, so there is no need for the publishedOn and ownedBy fields.

Basically, our users can now send their own createdOn and savedOn DateTime values, and their own createdBy and modifiedBy Identity values when creating a file or updating the file.