I believe this is something intentional. @Matt Finger will be able to confirm

1 hour ago, Marc said:

I believe this is something intentional. @Matt Finger will be able to confirm

Intentional for the Admin who has iframe embedded access to not being able to embed PDF files. Can you clarify why this is intensional? In v4 I was able to embed PDF files, why can I not embed PDF files in v5?

15 minutes ago, beats23 said:

Can you clarify why this is intensional?

I cant, and I may be incorrect. Hence the tag

The reason we require the sandbox attribute is for security purposes. Even though there are restrictions on who can use custom iframes, there are still other considerations we need to make. Cheifly,

• Not all admins may understand the full ramifications of allowing unsandboxed iframes. If the wrong member has access to it, it could lead to serious XSS leaks and a compromised site

• Different services require different permissions in the allow and sandbox attributes, so we'd really want support more granular options than include/exclude the attribute

• Even if the editor disallows it, we still need to be very careful that malicious actors cannot submit an embed that could compromise security using a manual HTTP Post.

Since 5 has been officially released we are currently focused on making it stable and ironing out bugs and issues, however in a future 5.x point release we will likely add more configuration options for embeds. Given the complex nature of embed security policies it's a feature that will require significant time and consideration to implement.

1 hour ago, Matt Finger said:

The reason we require the sandbox attribute is for security purposes. Even though there are restrictions on who can use custom iframes, there are still other considerations we need to make. Cheifly,

• Not all admins may understand the full ramifications of allowing unsandboxed iframes. If the wrong member has access to it, it could lead to serious XSS leaks and a compromised site

• Different services require different permissions in the allow and sandbox attributes, so we'd really want support more granular options than include/exclude the attribute

• Even if the editor disallows it, we still need to be very careful that malicious actors cannot submit an embed that could compromise security using a manual HTTP Post.

Since 5 has been officially released we are currently focused on making it stable and ironing out bugs and issues, however in a future 5.x point release we will likely add more configuration options for embeds. Given the complex nature of embed security policies it's a feature that will require significant time and consideration to implement.

Running scripts, which is already allowed, is no less dangerous than posting PDF files and Apple music share links on the website by the admin.

1. You already placed an iframe restriction for the domain; it must be whitelisted before it can be iframe.

2. You already placed a group restriction on who can use the iframe feature: "Advanced users only."

Then, when it comes to iframing an item, it is thirdly restricted by the Iframe sandbox, which the website owner cannot override. In v4, the option to give access to the source button to input raw HTML is highlighted with a very bright orange warning informing the website owner of the dangers of the HTML source button.

Why cannot a warning be the same for the iframe option in v5?

A lot of posted content on my website was made with rich text and PDF files; the rich text does not display correctly with dark mode, but it can be solved by clicking edit, then saving the post, and the editor automatically cleans those posts up. However, for any post with a PDF file, the editor removes the PDF file, and there is no viable option for me to replace the PDF file. The dark mode rich text issue is similar to your Docs page installation guide.

I depend a lot on being able to post PDF files on my website. Can this restriction issue be brought forward and discussed with your decision-making team for an urgent remedy?

Thanks.

As mentioned by my colleague, this is something that will be looked at in a point release. The focus at present is in bug fixes. From a back end point of view, the way those work is complex, and its very important anything like this is done properly, rather than with a quick fix.

Ok, but I hope it doesn't take too long.

I see this in v5.0.1 update: #3539: Better iframe allow attribute handling

However, I still cannot embed PDF files and Apple Music share links.

I do not see any changes made to the iframe sandbox allow attribute. It looks the same as before.

<p></p><div class="ipsEmbeddedOther" data-og-user_text="f"><iframe src="<___base_url___>/uploads/pdf_files/radio.pdf" class="ipsRawIframe" sandbox="allow-scripts allow-same-origin" allowfullscreen="" loading="lazy"></iframe></div>

Edited February 11Feb 11 by beats23