A helpful Twig extension – Fetch

6 thoughts on “A helpful Twig extension – Fetch”

  1. Hi Hasin,

    Though Twig extensions are great, they should only be used to register functions that prepare some data for use in a template. Fetching something from an external URL is very problematic and dangerous: if the external website fails to deliver its content, your page will fail too. Moreover: to display external content right into your page using this fetch function is a major security risk (it allows the external site to inject HTML and JavaScript right into your website). So: please reconsider this 🙂

    Kind regards,

    Matthias

    1. Thanks Matthias. We needed this extension in one of our current project where we had to fetch some “SAFE” urls (those urls are our own) to leverage the power of caching, as well as avoiding repeatedly loading objects from DB and passing to every twig template. This is where Symfony’s render/controller twig extension comes helpful 🙂

      My intention was to show the developers how to do it. Though I totally agree that there are a few risk in embedding external URL contents blindly – but that’s a different story and developer should take his own measurements to prevent such things from happening 🙂

      Thanks again Matthias and have a great weekend.

  2. This is a cool idea, but regardless of whether or not you own the other sites – they can still go down. Imagine you’re writing OO code and adhering to SRP – if one object fails, the consumer should have safeguards in (try/catch?) to mitigate this. So… If one of your own sites goes down, it shouldn’t affect another one. Definitely caution is advised here. At minimum perhaps some curl_error() checks would be useful here?

    Also this relies on cURL when perhaps relying an abstraction like Artax or Guzzle and not requiring the installation of third party software for HTTP requests would be preferable?

    Shouldn’t one be performing data retrieval from an external service somewhere with your business logic in the Model Layer, perhaps a ‘service’, anyway? This doesn’t really seem the best way with templating stuff IMHO.

    1. I understand what you’re saying here – but this extension is NOT a suggestion. Rather it’s a solution for a particular need which worked good for us mostly because the URLs are in the same domain, super safe and there’s no way they’ll go down unless the main app goes down. So the issues you’re mentioning here are relative to each one’s implementation. And it’s the developer’s own responsibility to understand the risk of embedding blindly and sanitizing the output before rendering. I didn’t go into that details because my goal was not that. Instead, my goal was to demonstrate how easily you can write an extension that may be useful. So the use case varies from person to person.

      Thanks again for your comment James, appreciated.

  3. Regarding your comment above

    > We needed this extension in one of our current project where we had to fetch some “SAFE”
    > urls (those urls are our own) to leverage the power of caching, as well as avoiding repeatedly
    > loading objects from DB and passing to every twig template.

    Actually thats what reverse proxies are for (“Wrong tool for the job”). I agree with @matthiasnoback, that this is very dangerous and by far not fail-safe. Beside that you load the whole application stack (webserver, maybe FPM, the application) to cache a single site. Put a nginx in front of your safe urls and set it up to work as a proxy with caching and you have the same result with muuuuch less overhead and far more reliable.

    > My intention was to show the developers how to do it. Though I totally agree that there are a few risk in
    > embedding external URL contents blindly – but that’s a different story and developer should take his own
    > measurements to prevent such things from happening

    Bad advises are still advises.

    1. Come on, it’s only dangerous when you’re embedding untrusted URLs blindly without sanitizing first. This one is for embedding the content from very trusted URLs which belongs to the same application. Now the reason we did it because we are not using ESI+Varnish. Reverse proxies are not just for avoiding “DB Calls” or whatever – they have a different purpose which is also important. Now to serve cached content, you can do that from the origin server by properly maintaining a caching policy and purging it when needed, you don’t really REQUIRE a reverxe proxy to do that.

      This extension fetches other controllers which generates contents that were used frequently, yet changes rarely. So instead of generating the content from the model/controller and then pass it to the view every time – we just passed the URLs. And that way, the purging or caching didn’t get any difficult either. The URLs which were fetched are very trusted as I said before, and belongs to the same app – and goes down only when the whole app goes down.

      >>Bad advises are still advises.

      You can do a hell lot of thing using file_get_contents() or curl extension. Of course you can do evil things and ruin your app if you donno what you’re doing. Now’ it depends totally on you how you’re gonna use it. Similarly this is extension is just an example of how this could be done. How you’re gonna use it is up to you.

      Anyway – thanks for your comment. Appreciated your concern 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s