XF 2.2 Posting Certain Images via Hotlink breaks Preview

[The Dark Wizard]

Hi,

One of the members of my community found what could be an interesting bug. When actually posted, you can see the image fine, but if you quote or edit this thread and see the image in the editor, you'll receive the white mountain icon.

The links in question

https://static.wikia.nocookie.net/aceattorney/images/3/3c/Yes_Ryunosuke.png/revision/latest?cb=20210618204245

https://static.wikia.nocookie.net/aceattorney/images/0/07/Shout_irassyai.xi_uk.png/revision/latest?cb=20170916223411

You can see it happening here on xenforo.com in this thread: https://xenforo.com/community/threads/testing-image-links.198252/#post-1536567

Example courtesy of @Xon

 

[Chris D]

Not something I can really consider to be a bug at this point.

It seems wikia is serving the smaller image. What causes them to be able to serve them differently in the different contexts, I don't know.

One factor could be the image proxy. The image proxy isn't applied in the rich text editor, but it is when posting. It could be that we're serving something cached in the image proxy but they've since added some sort of hotlink protection which means eventually when the image proxy cache expires the rendered in a post version may eventually display as it does in the editor.

 

[The Dark Wizard]

Not something I can really consider to be a bug at this point.

It seems wikia is serving the smaller image. What causes them to be able to serve them differently in the different contexts, I don't know.

One factor could be the image proxy. The image proxy isn't applied in the rich text editor, but it is when posting. It could be that we're serving something cached in the image proxy but they've since added some sort of hotlink protection which means eventually when the image proxy cache expires the rendered in a post version may eventually display as it does in the editor.

Interesting, thanks for the quick reply. That makes sense.

I'll keep an eye out for when the image proxy is due to expire (ours is set to two days currently) and see if those images break.

 

[Chris D]

It's definitely something related to the image proxy. But not related to caching actually. On a forum that has never seen the image before, with the image proxy disabled, I get the placeholder image. If I turn the image proxy on I get the correct image.

What is potentially also interesting is if I add to a plain HTML file:

<img src="https://static.wikia.nocookie.net/aceattorney/images/3/3c/Yes_Ryunosuke.png/revision/latest?cb=20210618204245" />

I get the placeholder image.

I think this has to be hotlink protection but the image proxy is somehow bypassing it. In fact, in the plain HTML snippet above it's actually returning a 404

 

[Xon]

The hotlink protection is probably triggering if the referrer is set and not to the original domain. The XF image proxy doesn't include the referrer while directly embedding in the editor does.

I bet setting Referrer-Policy: no-referrer or Referrer-Policy: same-origin http header will make it work for wikia link. But probably break for anything else.

 

[The Dark Wizard]

It's definitely something related to the image proxy. But not related to caching actually. On a forum that has never seen the image before, with the image proxy disabled, I get the placeholder image. If I turn the image proxy on I get the correct image.

What is potentially also interesting is if I add to a plain HTML file:

<img src="https://static.wikia.nocookie.net/aceattorney/images/3/3c/Yes_Ryunosuke.png/revision/latest?cb=20210618204245" />

I get the placeholder image.

I think this has to be hotlink protection but the image proxy is somehow bypassing it. In fact, in the plain HTML snippet above it's actually returning a 404

That is very interesting.

I guess the question should be is: Should be the image proxy be able to bypass a site's hotlink protection?

 

[Xon]

I guess the question should be is: Should be the image proxy be able to bypass a site's hotlink protection?

Nearly all hotlink protection is based on checking the referrer header, which may or may not exist.

 

[The Dark Wizard]

Nearly all hotlink protection is based on checking the referrer header, which may or may not exist.

Makes sense.