Currently the iframe serving a protected embed is served from site_url( '/protected-iframe/' . $embed->get_id() ). This seems wrong, as the point of this plugin is to be sure to serve these iframes from a separate domain from the site.

This also causes the postmessages being used to resize the iframes to fail, because the target origin specified in the postMessage call doesn't match the actual document origin of the iframe. As a result, frames are not resizing correctly and are cut off at 150px height.

The offending line seems to be here:
https://github.com/humanmade/protected-embeds/blob/master/protected-embeds.php#L77

Hi Team,

I've followed instructions and installed this plugin but I don't see the Add Embedded button added to the Wordpress Editor like in the attached screenshot. Please suggest

Thanks,
Amar

Perhaps not necessary given the intended usage but it's an extra layer of security, especially where multisite SSO etc are concerned.

Would be good to look into making the iframes resize nicely for small/larger screens etc... there's a vanilla js version of fitvids that might be usable in conjunction with the postmessage code.

Appears that Shortcake / ShortcodeUI is required when not running on WordPress.com.

Is shortcake included in WordPress.com / VIP? It might be that we need to change the description to reflect what is required to add this to a project.

Hi Joe,

VIP brought the following issue to my attention:

We just noticed that PROTECTED_EMBEDS_DOMAIN will load the site homepage. As you probably know, the point of using an alternate domain to host embeds is to protect login cookies from XSS attacks. While it's probably not possible to get a login cookie from the protected embeds domain right now, it would be best to protect against some future bug that does make it possible. Do you think we could either wp_die() or wp_redirect() to the site homepage when that domain isn't serving a protected embed?

This seems like a general concern when implementing a protected embeds solution like this. What do you think about adding a check on init or parse_request that bails early for requests on the protected embeds domain that don't have have the "protected-iframe" query var set?

It would be good to be able to call something like Protected_Embeds\Embed::create( $html );, which should create the post, insert it into the database, and return the shortcode string for post content.

Could we please confirm the license for this project?

• Add a LICENSE file to the project root.
• Specify the license in the WP plugin header License field.
• Specify the license in the composer.json, if available.

https://github.com/humanmade/protected-embeds/blob/master/protected-embeds.php#L170

At this line $wp->query_vars['protected-iframe'] won't be defined on edit.php page or any post request page. It is throwing wp_die() on those pages. I know it is used for redirect rule and iframe loading support but parse_request gets called on all page having post.

The code is currently running a query to create a DB table if doesn't already exist on admin_init.

Due to how often admin_init is triggered this is potentially creating a large number of unnecessary queries, for instance we have literally seen the create_database_table() function called millions of times in a single day on one of our big sites.

It would be more efficient to check the table exists on activation and upgrade rather than on every admin action.

Please give me a shout if you would like me to work on this with you.

Thanks.

It would be great to pull this plugin as a regular Composer dependency similar to the rest of the packages https://packagist.org/packages/humanmade/