Embedding integration failure when browser strips referrer, bad fallback

Feature
1

via the html/js embed code in customize > embedding, like this:

Allowed hosts: blog.example.com
Class name: blog
Path whitelist: /.*

Username for topic creation: system
Maximum number of posts to embed: 0
Truncate the embedded posts: checked

and

DiscourseEmbed = { discourseUrl: 'https://forum.example.com/', discourseEmbedUrl: '{{@blog.url}}{{url}}' };

Expected result: display a link to the corresponding Discourse topic for the blog post. The link shows the number of comments in the forum topic.

We’ve seen in various cases:

Error Embedding
Referer:
The referer did not match any of the following hosts:
blog.example.com

We tracked down the error to happen on browsers stripping/spoofing the referrer header. Apparently the Discourse-supplied embed.js uses the browser referrer string to match the allowed host.

Most browsers will send referrer by default. The only exception we found is older versions (iOS 11) of Firefox/Firefox Focus. But some privacy-oriented plugins like Privacy Badger or others may strip the referrer.

The ideal solution might make this function (at least somewhat) without the referrer, but at least a friendlier and more informative error message could be along the lines of “your browser has disabled sending of referrers”. At least people should not think something else is broken with the feature…

3 Likes
2

I mean, I guess, but the only “improvement” would be

The referer was either not sent, or did not match any of the following hosts:
blog.example.com

Which seems like an exceedingly minor nitpick.

3

Yeah, if there’s no other workaround to the underlying issue.

It would be nice for others who experience the same thing to avoid too long troubleshooting since we’ve identified that common privacy plugins may have this effect. So, whatever makes the issue clear seems nice at least…

4

Well, the copyedit is easy enough, and could be helpful, so I’ve done that at least.

3 Likes