I see quite a lot of misconfigured sites that look to use various methods to block ‘hot’ linking of images, but return links to such images in the embedding data e.g.
Checking with http://debug.iframely.com/ I really think this isn’t a Discourse problem per se, but it does look poor.
One thought is that the onebox creation could retrieve the image when cooking the post and either store a thumbnail to serve later, or if it couldn’t be retrieved act as though there was no image specified.
Storing a copy of the image would be fairly robust and future-proof, and I think should fall under fair-use for copyright purposes (the original site isn’t going to be worse-off for the reuse of a 130x90 thumbnail which was retrieved from meta-data, though IANAL).
Failing that I tried making a component to catch the error event on images and then add a class to display:none them or their wrapper. I’ve not succeeded yet as I got bogged down in decorateCookedElement()… I’m not sure if I’m looking in the right place.
So, is it just me that seems to suffer broken images frequently in oneboxes - has anyone else got a workaround?
It’s obviously not at cook time, because you don’t put web requests on that critical path, but we queue it and download the onebox image in the background.
We wait editing grace period (default 300s) to download it if download remote images to local (default true).
It’s important to be careful and ponder the repercussion when changing the default settings. We ship with optimal choices out of the box, and deviating from those can have unintended consequences .
