Orchard Core 1.2.1 release, Remove exists check for blobs - This week in Orchard (20/01/2022)
Orchard Core 1.2.1 is now available to fix some security issues. Check out this post to know the content of this release of Orchard Core and to see the latest features of the framework!
Orchard Core updates
Remove exists check for blobs
Instead of querying the blob, if it exists any time, we just try to get it, and maybe the server will return with a BlobNotFound error. This way, if it's there, we prevent one external network communication to check if it's there before asking for it. So, we just ask for it, and then if it fails, it fails. It's a pretty common issue with Blob Storage because of its high latency you need to do as few communications as you can.
Starting background tasks without waiting for initialized tenants
You can have a scenario where you would like Orchard itself to starts its background tasks without the need of a request for each one of the tenants. Until now, you need to make a request to as parent tenant and to every child tenant to be sure background tasks of each tenant start to run. So, by default background tasks are waiting for their shell to be lazily built on a first matching request. From now, you have a ShellWarmup bool option in the appsettings.json that allows you to eagerly build shells just before executing their first background task.
News from the community
Orchard Core 1.2.1 release
Orchard Core 1.2.0 has been released on the 6th of January. But after a few days, a vulnerability security issue has been filed. That's the reason why the community had to create a new Orchard Core 1.2.1 release, to fix that security issue. You can update to the new version as usual. If you open up nuget.org and search for the OrchardCore.Application.Cms.Targets package, you will find the newest released version of Orchard Core! But let's see the fix that is in this release!
It's not critical in the way that only users that are authenticated and have access to the dashboard can do things. Looking at the security issue and then how to not have them anymore. These are XSS issues, which means you can inject custom JavaScript in a page that could be triggered automatically, and then if you inject some fancy JavaScript you can force a user to submit queries and on this site, you could extract secrets or have them do things they don't want to do on the site.
We encode everything we output. This means if the thing you output contains some JavaScript, it will be encoded, which means it will be rendered and not the JavaScript itself to be executed. In this case here, what was happening is that the translation was called on a variable, but we can't translate it. When we call T[], the IHtmlLocalizer will lookup for this text. If it finds this text in the translations, it will render the translation, otherwise, it will render the text as-is. That's why we always pass the English versions, such that if it doesn't find a localization, it will render this text in English. So, we don't have to create the translation for English, we just use that key that we passed.
But the T[""] can contain HTML. And that's how we do to translate notifications, links, and stuff like this. And because it can contain HTML, the @ before that will just render it as is. So, whatever is passed there, it will be rendered as-is and not encoded. If we put some HTML or JavaScript inside that, this will be rendered as is and not encoded. What happened there is that when we do any string, like @T["Add widget"] is fine because we know this is a static string to generate. So, we know what we are rendering. But when we do it in a variable like @T[item.value], it can contain anything. And we don't know what it contains. And if it's user inputted, then there can be bad issues. So, we should never translate a user inputted value like this.
This is an encoding issue over a bug. This is a list of SelectListItem, which itself contain a localized string instantiated value. There is no reason to use a localized string here. We use localized string as a type when we know that the property needs to be a localized string and should be a sign with a call to T for instance. This piece of code from the DashboardController is just to list the display name of the content type and the technical name of the content type. It's just a list of content types to allow you to create a new content item based on the type.
The first solution is to don't translate variables. We have the design and started the PR for dynamic content translations, which is supposed to fix that, to provide a solution to be able to translate content types, permissions, and all the things that are user inputted and dynamic in the database (not static text). We should either not translate dynamic variables or use the new localization PR.
The second option is to explicitly encode it for just this vulnerability. In this case, it's not breaking anyone, and it's secure because here, we explicitly translate the encoded value of the display name. So, it would break people who have spaces in their content type display name, because now they have to translate Foo content&nbps;type not Foo content type.
.NET Foundation Most Active Community Projects 2021
Shaun Walker shared this image on Twitter that contains the most active community projects based on the number of pull requests, the number of commits, and the number of new contributors.
As you can see, Orchard has 1507 pull requests in 2021, which is great. Orchard has 1291 commits, which is weird. Why do we have more pull requests than commits? Do we really close that many pull requests? We have some mini PRs created by Dependabot.
And we haven't talked about which projects are using squash and merge and which projects aren't. But it's still a nice thing to be able to see Orchard in the top 10! :)
Orchard Dojo Newsletter
Lombiq's Orchard Dojo Newsletter has 238 subscribers! We have started this newsletter to inform the community around Orchard with the latest news about the platform. By subscribing to this newsletter, you will get an e-mail whenever a new post is published to Orchard Dojo, including This week in Orchard of course.
Do you know of other Orchard enthusiasts who you think would like to read our weekly articles? Tell them to subscribe here!