feat: add iframe permissions support

[beaugunderson]

• https://canvasmedical.atlassian.net/browse/KOALA-2500

[aduane]

We want these to be specified in the manifest rather than in the effect. This will allow the permissions to be surfaced on an extension listing page.

[beaugunderson]

We want these to be specified in the manifest rather than in the effect. This will allow the permissions to be surfaced on an extension listing page.

hmm... the permissions will need to be pairs of url,permission then, since one plugin may launch modals with different URLs and may not want the permissions to apply to every URL, does that work?

[aduane]

Yes

[beaugunderson]

@aduane how does this look?

example:

{
	...
	"url_permissions": [
		{
			"url": "https://example-a.com/testing",
			"permissions": ["microphone"]
        },
		{
			"url": "https://example-b.com",
			"permissions": ["allow-same-origin", "microphone"]
        },
	]

[aduane]

I think the structure looks good, but I wonder about the name. Should it mention iframe in the attribute name? Should we merge this with what we have for origins? That would require a period of dual compatibility and a deprecation cycle, though.

I'm trying to think backwards from what we would display on a plugin's listing page.

This plugin can embed the following URLs:

url	permissions
https://canvasmedical.com	microphone scripts cookies from same origin

[beaugunderson]

you could have origins and origin_permissions... but that does seem overkill, personally I'd just want all the configuration grouped under each origin

[aduane]

Like this?

{
  "other_stuff": "..."
  "origins": [
    {
        "url": "http://www.canvasmedical.com",
        "permissions": ["allow-same-origin", "microphone"]
    },
    {
        "url": "http://example.com",
        "permissions": ["scripts", "microphone", "allow-downloads", "usb"]
    }
  ]
}

We'd be mixing concepts here. Some would belong in the sandbox attribute, others would end up in the CSP. I think the usb one (which we don't really need to worry about) would end up in headers(?)

Definitely a good developer experience, we would just have to take on the burden of sorting them out on our end (which is a mark of a good platform! shift the complexity away from the developer and towards the platform)

[beaugunderson]

yes, the other PR already sorts them into the right place (allow and sandbox respectively)

[aduane]

I like it as long as we identify when the "old way" of defining origins is used and provide a warning / a cutover date for when the "new way" is the "only way".