I would argue that a data uri is technically not external so I also tried the following, which also fails to lint:
permissions:
content:
images: < invalid
- 'data:'
I also tried:
permissions:
fetch:
client:
- '*'
Which gives:
index-wWxwMUh6.js:128 Refused to connect to 'data:image/svg+xml;base64,<STUFF>'
because it violates the following Content Security Policy directive:
"connect-src 'self' https://api.atlassian.com/metal/ingest *".
Note that '*' matches only URLs with network schemes ('http', 'https', 'ws', 'wss'),
or URLs whose scheme matches `self`'s scheme.
The scheme 'data:' must be added explicitly.
Looks like I got to 10 likes here so a few vendors also care about this. Any chance you can ping the relevant team for a response here @ibuchanan / @tpettersen ?
Hi @BPB , do you have a code snippet on how you’re trying to render your data URI ?
I have an example here of using a data URI in an image tag and this works without any permissions required in the manifest
const containerRef = useRef<HTMLDivElement>(null);
useEffect(() => {
console.log("Script running from useEffect");
// Creating and appending an image element, similar to your original script code
if (containerRef.current) { // Check if the ref.current is not null
console.log("Container ref is not null");
const image = new Image();
image.src = "data:image/svg+xml;base64,<STUFF>";
image.alt = "Dynamic Image";
image.style.height = "auto";
image.style.objectFit = "cover";
containerRef.current.appendChild(image); // Append the image to the div
}
}, []);
<div ref={containerRef} style={{ maxWidth: "600px" }} />
I’ve used this example and had no issues with getting the image to render
const containerRef = React.useRef<HTMLDivElement>(null);
React.useEffect(() => {
console.log("Script running from useEffect");
// Creating and appending an image element, similar to your original script code
if (containerRef.current) {
// Check if the ref.current is not null
console.log("Container ref is not null");
const image = new Image();
image.src =
"data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'%3E%3Ccircle cx='50' cy='50' r='40' stroke='green' stroke-width='4' fill='yellow' /%3E%3C/svg%3E";
image.alt = "Dynamic Image";
image.style.height = "auto";
image.style.objectFit = "cover";
containerRef.current.appendChild(image); // Append the image to the div
}
}, []);
return <div ref={containerRef} style={{ maxWidth: "600px" }} />;
I think SVG probably should not be encoded with base64 - I don’t know why but it didn’t work for me. I’ve been using this online svg-to-data-uri encoder to do conversion for SVGs and it works perfectly for me. The encoder also noted that:
I appreciate the workaround suggestion. In my case I have a library I use which encodes it as base64 because it works with more than svg/xml. This is also supported by the browser. The only issue here is Forge’s CSP implementation hence I am asking for there to be an appropriate adjustment for how to handle the scenario.
Hey @BPB , I tried your example but I was getting an invalid URL error suggesting the data URI is incorrect. I tried this example of a base 64 encoded svg and it’s rendering okay.
Forge isn’t intentionally blocking base64 encoded images but if you’re having issues I would suggest either trying a different format or double checking the data URI is correct
The error I get within Confluence is not a rendering error, this is a CSP issue that only happens in forge:
index-wWxwMUh6.js:128 Refused to connect to 'data:image/svg+xml;base64,<STUFF>'
because it violates the following Content Security Policy directive:
"connect-src 'self' https://api.atlassian.com/metal/ingest *".
Note that '*' matches only URLs with network schemes ('http', 'https', 'ws', 'wss'),
or URLs whose scheme matches `self`'s scheme.
The scheme 'data:' must be added explicitly.
Hi @BPB , I understand. I’m having issues reproducing the error you’re seeing in Forge as I’m getting an invalid URL error instead of the CSP issue that you’re seeing when trying to render your data URI. As this seems like a unique issue, I suggest raising an ECOHELP ticket here: https://ecosystem.atlassian.net/servicedesk/customer/portals so the team can look into this problem more closely and try to debug your issue from there