New permission checks for dynamic properties

Forge
1

A recent changelog entry announced new permission checks for icons defined using dynamic properties. However, it’s not clear from the announcement whether this is just a linter warning for now or if the checks are already enforced.

If we want to deploy a new version to production, do we have to take these new checks into account?

The reason why I’m asking is that there is currently a bug that prevents us from using bundled resources as icons in dynamic properties and I would like to avoid adding new permissions to the manifest.

I’ve also noticed that a linter warning is shown for every file in the src directory, not just for the dynamic properties module. Also, the warnings cannot be resolved, even if the necessary permissions are included in the manifest.

1 Like
2

Hi @klaussner

Thanks for reaching out!

We have first released the linter check (and warning) ahead of enforcing the permissions. The enforcement itself is planned to be enabled in the coming day or so (a separate announcement will be communicated on our Forge changelog). This means that all new deployments after this date will require the permission to be added to the manifest.

If the bundled resources is not working, you will likely have to add a URL instead and add this URL to the list of permissions of your app.

As for the linter warning, we have opted to add a generic warning that gets displayed as soon as you are using a dynamic properties module. The warning cannot be fixed (via the usual lint --fix) so it will always be displayed as a reminder.
We have opted with this approach because there was too many combinations of how to define an icon property in an app code, and the linter would have not necessarily picked all those combinations.

I hope this helps.

3

Thank you for the quick response, @XavierCaron!

I really hoped that the bug would be fixed before the checks are implemented. Having all users confirm the allow access screen again is a bad user experience, especially when there’s a better alternative (bundled resources).

4

I just tested an alternative to bundled resources that should—in theory—work without changes to the app’s permissions. Dynamic properties accept data URLs, so we can return a Base64 representation of the icon:

export function handler() {
  return {
    icon: "data:image" + "/svg+xml;base64,PHN2ZyB3aWR0aD0..."
  };
}

However, the linter returns an error for data URLs (I tricked the static analysis by concatenating the two strings so that the linter only shows a warning instead of an error):

The domain data:image/svg+xml;base64,PHN2ZyB3aWR0aD0... is not included in the external images permissions of your app manifest  egress-permission-required

Will the permission checks accept data URLs, @XavierCaron?

5

Hey there! So, I understand that you’re wondering whether the new permission checks for dynamic properties are already in effect or just a linter warning. I’m not exactly sure either, but it’s probably best to check the documentation or reach out to the developers to get more information on this.

If the new permission checks are already being enforced, then we’ll need to take them into account before deploying a new version to production. But if it’s just a linter warning, we can probably ignore it for now.

It sounds like you’ve run into a bug that’s preventing you from using bundled resources as icons in dynamic properties. That’s frustrating! I suggest trying to find a workaround or reaching out to the developers to see if they plan on fixing the issue in a future release. It’s important to make sure our application is working properly before we deploy to production.

6

Hi @klaussner

Thanks for the feedback.
I can confirm that this approach is fine and will be allowed by default.

We will however need to release a CLI linter change so the error message disappears. This will be done soon.

We will also update the documentation accordingly.

Cheers

3 Likes
7

Awesome, thank you very much, @XavierCaron!