Sitecore JSS hiding data in props

 Sitecore JSS props

A small extension to my post on Sitecore JSS and extranet security which I wrote in July. If you haven't read that one, please do so first as I will try not to repeat too much here.

What is important to mention is that we are sending roles that are allowed to see the pages along with the page data. These roles are selected in a multiselect field.  This way the front application is in charge of the security as it should. 

We noticed a problem however when we looked at the source code of the generated pages. They were listing our role id's and names. This is of course information that we would rather not show to everyone. 

Hiding page data

So our problem is data from the page that we would like to use, but not show to users.  In our case it was security related, but that could be any data of course.

We could try to change the output and adapt the way a MultilistField sends its output. I would assume the GetMultilistFieldSerializer or MultilistFieldTypeFactory might be a good start, but actually I don't want to change that behavior just for 1 field. It seems like a messy solution, especially if we would get more data like this. As it is the front app that is putting this data in it's output, it is that app's responsibility to keep it hidden.

A MultilistField will by default show the id, the url, the name, the display name and the fields of the selected items. But even if we would just have the raw value -which is the minimal that we need for our functionality- we should hide that from public eyes.

I want to mention again that I am nowhere near a NextJs expert so for me this is gibberish but my front-end companion came up with a function that is now used to filter out the "roles" field:

import { SitecorePageProps } from 'lib/page-props';

export const whiteListProps = async (props: SitecorePageProps) => {
  delete props.layoutData.sitecore?.route?.fields?.roles;
  return props;
};

In the [[...path]].tsx this function is used on the props.

As a non-expert on the matter, I was surprised to see that all data coming from Sitecore was visible in a browser. Assuming there are more non-experts out there, I hope this post makes some sense and might keep some sensitive data hidden.

Upgrade Azure App Service Deployment task to v4

Task 'Azure App Service deploy' version 3 (AzureRmWebAppDeployment@3) is deprecated

Azure release pipeline

Yes, this is not a post about the Sitecore platform as such but as it is related to one of my Sitecore projects it might be related to (many) more. For a Sitecore website deployed in Azure PAAS we are using Azure DevOps to deploy and we recently noticed in the release pipeline that some stages gave warnings - although they still succeeded. 

The warnings said the Azure App Service deploy task is deprecated and we should use the newer version:

Task 'Azure App Service deploy' version 3 (AzureRmWebAppDeployment@3) is deprecated
The AzureRmWebAppDeployment@3 task is deprecated, please use a newer version of the AzureRmWebAppDeploy...

So I checked the release pipeline and decided to "upgrade" the related tasks called AzureRmWebAppDeployment from v3 to v4. It looked pretty simple - just a few minor changes in the configuration and we were set to go. 

As a test I created a new release and the deployment steps seemed to work but our Unicorn sync failed with a disturbing message: the path /unicorn.aspx was not found. When we checked the files on the server with the App Service Editor we noticed the file wasn't there.. actually, almost all files were gone. 

Not knowing what had happened I redeployed the stage to see if it was some temporary issue. The second attempt however failed rather quickly: An error was encountered when processing operation 'Create File' on 'C:\home\site\wwwroot\ApplicationInsights.config. Was something really wrong with this v4? I reversed the task back to v3 and tried again, but the same error appeared. So it was not the deploy task but probably the Azure instance itself. 

Next attempt was to try and create a config file manually with the App Service Editor. Strangely that failed as well (error 409). Clearly the Web App was not behaving as expected but didn't show any errors, nor issues in the resource health. It was when I checked the Advance Tools that I finally started to get an idea of the issue. 

When opening Kudu I got this warning:

So I start searching what this WEBSITE_RUN_FROM_PACKAGE means. I noticed that this environment variable was indeed created. When I delete it, I can create files again. At that point it was time to read the documentation 🙂

I found the readme files for both version 3 and version 4 of the Azure App Service Deployment task and especially that last one was interesting as it did explain about this RunFromPackage.

RunFromPackage

Creates the same deployment package as Zip Deploy. However, instead of deploying files to the wwwroot folder, the entire package is mounted by the Functions runtime. With this option, files in the wwwroot folder become read-only.

Apparently, by default (when 'Select deployment method' is not checked) the task tries to select the appropriate deployment technology given the input package, app service type and agent OS. Maybe it was because we deploy zip files (especially for serialization files this is much faster) but Azure clearly thought it had to use the RunFromPackage. This created the environment variable causing our Web App to set the wwwroot read-only.  Problem found!

To fix it, we had to set the deployment method specifically for all the deploy steps in all stages.  

 Once we removed the WEBSITE_RUN_FROM_PACKAGE environment variable again and deployed with the deployment method set everywhere all was working fine and we have no more warnings.