So funny thing about #kbin. I post a photo thread. I go to my profile and see the thread. I click on the image preview icon. I immediately get sent to https://kbin.social/u/undefined. Not only is Mr. Undefined a real user, hello @undefined, but somehow my image now directs to his profile.
As I dig into Firefox dev tools to find out why, I see that uBlock Origin has blocked the request for my image. But that’s odd, I have no specific blocking rules for kbin, and kbin.social doesn’t run ads. What’s up?
So it turns out my image got uploaded to the following URL: https://media.kbin.social/media/ad/b2/adb203028331eada7f99f2b4547cbc0a7efc0ba4e203a71d9d193c02d38aa4f1.jpg
…/media/ad/… That’s what uBlock was upset about. So by blocking that request, the target of the AJAX fetch is… undefined. Hence my trip to a random user’s profile. XD
@e569668 I was thinking about it, but since it had to do with software I was running personally I figured it isn’t really kbin’s fault. Then again, a simple solution would be to blacklist “ad” as an index folder for uploaded media. I’ll toss in an issue and y’all can discuss.
1085
@HarkMahlberg I assumed it was a default ublock rule and not one you added so I imagine a lot of people might run into this. Well, “a lot” depending on how often a filename’s sha256 hash starts with
ad
. At the very least it’s probably good to know about it, even if nothing is changed. But perhaps there’s enough reason to use a different system to name image caches like the name generators a lot of image hosters seem to use. I guess it’s in the devs hands now :) thanks for sharing it@e569668 Oh, I meant to say that my running ublock origin at all was personal, and not everyone is going to run ublock origin. But to clarify, the rule that triggered the bug came from a default ublock list: https://easylist.to/.