Closed kiwiz closed 2 years ago
This looks good and would merge as-is if you want.
To answer your questions though:
p.AllowAttrs("sandbox").OnElements("iframe")
and RequireSandboxOnIFrame()
... but I have avoided doing anything implicit outside of the helpers (see https://github.com/microcosm-cc/bluemonday/blob/main/helpers.go#L176-L189 as an example... it isolates complexity to the helpers and keeps the core interface simple and unsurprising).AllowIFrames
to do the job for you (see the first point)All-in-all... a nice addition, and yes there's a nit, and yes there's scope for a simple helper to add iframe support which would encapsulate the recommendations... but the core PR looks fine, so the choice is up to you, should I merge and release or would you like to add the helper and dedupe and then I'll merge, etc
Thanks for the feedback! 1 & 3 are addressed in the new commits and I think 2 might be a non issue.
Just to be explicit though:
Calling RequireSandboxOnIFrame
will add sandbox=""
to all iframe
tags that don't have it, which would change the behaviour of the iframe
(but is the point of this feature).
However, if the input HTML has an empty <iframe></iframe>
, that gets removed entirely. I don't think an empty iframe
tag can be used for anything interesting. Some JS could manipulate it down the line, but you'd expect an id
or class
attr to be populated.
If that sounds sane to you, then I think this is ready to go. :+1:
Sounds sane to me, will merge and release.
WIP implementation of
RequireSandboxOnIFrame
.Open questions:
RequireSandboxOnIFrame
internally callp.AllowAttrs("sandbox").OnElements("iframe")
, or should we leave that to the user?<iframe>
does NOT have asandbox
attribute, the entire tag is omitted entirely. However, what we actually want to do is keep the tag and enforce a blanksandbox=""
attribute. (Might be related to #68?)sandbox
attribute (ex:allow-downloads allow-downloads
->allow-downloads allow-downloads
). Is that something we should do?Closes #135