Embedding things using its URL and oEmbed
During content creation, it is not uncommon to refer to external content, from simple documents or web pages to multimedia or specific content such as tweets or posts from other platforms.
Links are one of the pillars of the web, but sometimes you want something more integrated. If you want to refer to a tweet, why not embed it in our content? A very common case is a Youtube or Vimeo video so that it can be played without leaving the page. Another case can be to visualize a Scribd's PDF file.
Embedding contents with oEmbed
To achieve this there are Drupal modules specific to each case, or generic but focused on one area, such as those that integrate video services. Another strategy is to use something like oEmbed. oEmbed is a format that allows you to describe URL representations that can be embedded in other web pages. That is, it is a way by which a provider (YouTube, Twitter, Scribd, Flickr, etc) can describe to a consumer (our Drupal website, for example) how to display a provider's resource.
Or let's look at a practical example. This article has been tweeted by the Twitter Metadrop user. This tweet has a URL. Well, using oEmbed is enough to use that URL to get this result:
Fantastic! Obviously, the article has been tweeted and then quickly edited to add the tweet's URL, circular references were never easy!
URL Embed module
Embedding content using oEmbed requires the Drupal site to support this format. But we are lucky since the Drupal's Media Initiative has created the URL Embed module. The module integrates oEmbed and allows it to be used in CKEditor fields in a very simple way through a simple dialogue in CKEditor itself.
Embeding a URL in this article on a new autoreference.
The list of supported providers is long, and includes providers of video, documents, photos, and many other things I honestly don't know about.
A Flickr's album?
Drupal Camp Madrid 2017
A SlideShare's document?
There's a delicate matter. Through oEmbed, we receive HTML data from external sources that are displayed on our website. Potentially, this can create Cross-Site Scripting problems: if we insert a malicious JavaSript code, it will have access to our domain's cookies, for example. To mitigate this problem oEmbed suggests displaying the external data on a different domain using an iframe. Unfortunately, URL Embed does not have this possibility. Does this mean that this module opens a security hole? Not exactly. The point is that we must trust the provider. For example, it is not probable that a known service as YouTube to return malicious code in its oEmbed response, just like other services such as Vimeo, Flickr and so on (although not impossible, of course). But less well-known services, and therefore less subject to scrutiny, are more likely to return code that is not entirely secure, either intentionally or unintentionally. If we allow oEmbed responses from any provider we'll probably face some security problems in the future.
Therefore, it is enough to know the security implications and act with the head, as it usually happens in real life.
URL Embed is a good module even though it is still alpha. Today it has almost 2,300 installations and in our tests it has not failed. It is true that it is looking for maintainers and that it would love some contribution, but it is good enough to be used, always taking into account the security considerations.