Embedding pens from CodePen

Looks like codepen don’t support oembed which is a shame, because if they did it would be as simple as whitelisting them. They do support open graph, but it looks like a simple summary of the pen and not an embedded widget.

I’ve sent them a support request asking about an iframe oembed version, hopefully they will respond.

6 Likes

That’s great. Thanks for looking into this, guys. I look forward to a reply from them. :smile:

Yes, the current result is certainly acceptable, but not the ideal.

We plan to support oEmbed. Just gotta get to it =).

4 Likes

Thanks Chris! That’s great to hear. :slight_smile:

Hey Team,

oEmbed for CodePen is ready to rock: http://blog.codepen.io/documentation/features/oembed/

Lemme know if you have any questions or anything.

10 Likes

Excellent when we work on oneboxes this week @eviltrout make sure that is white listed now!

That’s great. Thanks Chris and Jeff!

Works great!

(well, except it does not work in mixed http/https environment…)

How about this simplified codepen? http://codepen.io/coding-horror/pen/Atjvw

Nope, it has to be the first post too… or possibly an https mixed content error? Any idea on fixes @chriscoyier because this is really cool!

[blocked] The page at 'https://meta.discourse.org/t/embedding-pens-from-codepen/13578/9' was loaded over HTTPS, but ran insecure content from 'http://codepen.io/msvbg/embed/sGIof?height=300&slug-hash=sGIof&default-tab=result&host=http%3A%2F%2Fcodepen.io': this content should also be loaded over HTTPS.

Ah yeah, the iframe src being returned is HTTP, which is our bad because we otherwise totally support HTTPS. We’ll probably just change it to always return HTTPS because why not. I’ll hit you up here when it’s done.

Looks like it is working now! Excellent!

edit: hmm, it was working in iOS Mobile Safari at least…

Seems to be working fine to me. (Just tested it on our installation, and it’s working well.) Great work, guys. :smiley:

OK this is actually fixed on our end now. If the referrer is HTTPS, the embed will be. Otherwise it won’t. I thought HTTPS-everywhere would be good, but that breaks Pens that link up any non-HTTPS resources (e.g. a user linking up a copy of bootstrap from somewhere HTTP). So we’re just going to mimic where it was requested from.

Test:

The ones above might be cached or whatever so are still showing as blocked (in desktop chrome) but hopefully this one works.

1 Like

Hmmm. Still doesn’t seem to. Maybe the URL you make the oEmbed call from isn’t secure?

Here’s an HTTPS test I did that seem to work: https://css-tricks.com/https-test/

The HTTP request that Discourse sends to fetch and cache the embedded content (from the onebox gem) doesn’t set a referrer header. Maybe default to HTTPS unless the referrer is a HTTP URL?

CodePen now defaults to https if no referrer is present or the referrer used HTTPS.

We think it’s good to go. Testing below.

7 Likes

Just an update, we had this working in the past but it became a security problem, people could abuse it, so we no longer enable it by default. You can still enable it if you white list it in site settings.

https://github.com/discourse/onebox/commit/af3c3494ed98d78d0db15e61aa1f25cf0580c06c

2 Likes

Would love to hear about what security problems you had.

2 Likes

There are two particular vectors that are painful

  1. Playing sound, so people could create really annoying topics
  2. Consuming high CPU by running stuff in tight loops with timers

Maybe the embed should have a mode where it runs nothing until the user opts in?

4 Likes