Pictures in Posts

Post Reply New Topic

Ah, thank you, that seems to work when I use Bing, it never would have occurred to me that using Google Images might be the problem.

Use something like this: https://imgflip.com/memegenerator

Upload your image, generate the meme, click on the picture and copy the image location. Bob's your uncle.
There are better programs than Memegenerator, but I am too lazy to use them.

Some Google image links work, while others don't.
Go figure.

When I copy a Google link, I copy and paste it into Wordpad, as an example.
If it produces a URL, all is good.
If it just pastes pages of rubbish, try another pic or go to the source of the Google search pic.

Life was not meant to be easy.

OT - is anyone other than me having trouble seeing Cornflake's recent post to the "Images in Numbers" thread?
He says "works for me".

It was a computer card representing number "5525".

We have discussed possible causes and effects on PM. It might be on my side - or it might have something to do with cookies on his side (etc). Hard to tell for sure.

For images that I have created (scans, screenshots, etc) I have found

https://tinyimg.io/

to be super easy and straightforward, and it works with WP.

Here is a diagram I just posted on an arduino forum

Looks like this:

See my post to "Images in Numbers", plus those following: viewtopic.php?f=30&t=199097&start=4448#p8837674

^ The image in question is a WebP image, not a jpeg as its filename would suggest. Not all web browsers support them properly yet.

Reading further in the thread, I spoke too soon, that doesn't appear to be the problem. You got a 403 error for the image, then a captcha challenge from scan. I wonder if the image displayed properly after you completed the captcha challenge? That you got a captcha challenge from scan would explain why you couldn't see the image - scan is blocking you on the assumption you are an undesirable robot or some other automated entity. Why you were flagged as such is a good question, but one we can only guess at.

Oops, so it is. So much for trusting the given file type.
Also explains why Fenn downloaded it as RIFF and converted to jpeg locally. (per PM chat)

Think I'm honing in on the problem:

If I try to download it outside of a browser I get the same 403:



There is some sort of check going on between requesting the image and scan ponying up the actual data. wget and your browser appear not to be passing it.

Those IP addresses belong to Cloudflare Inc. - I think that Mr. man-in-the-middle Cloudflare is the issue here. Not being a web developer I can't offer much advice on where to go from here. Perhaps a privacy tool is interfering with cloudflare checks?

I also get 403 when using wget - but using Google Chrome, Vivaldi, Konqueror or Chromium with the same link just display the image without comment

Using Nord VPN as "from" the USA in Google Chrome and accessing the same image link returns the nicely wordy message:
"403 - Access Denied. We are not accepting traffic from your IP Address, ISP, Region or Country, this ban may be temporary and we may be able to accept traffic from you again soon.
Please try again later"

More interesting stuff:

When I run wget again with a genuine looking user-agent, I don't get a 403 - I get the image, but an actual JPEG (ff d8 ff e0 00 10 4a 46) image - not WebP.

So we can tell two things about the image url:
Firstly: there are tests involving the user-agent - some privacy tools change these, it might have triggered the captcha.
Secondly: there is at least some kind of (probably javascript) testing to tell whether your browser can support WebP, and sends either JPEG or WebP depending on the results.

So check your javascript settings and/or privacy tools in use.

I've run into a problem like this before, though that was somewhat more amusing. Fnord once linked an image that didn't display on my fairly paranoid browser setup - any attempt to retrieve the image without a fully insecure/unguarded browser redirected you to a porn site.

Same here with wget when using --user-agent="Google Chrome" - a jpeg file is successfully retrieved.

I think you're right about the reason why a jpeg file is returned - when the browser isn't recognised as one supporting WebP a jpeg is substituted. I guessed at the Google user agent name but it's proven by using "Monkey Poo" instead: a jpeg is still retrieved.

See my post above yours (maybe crossed in transit?) - there is also an issue with the source site refusing USA IPs.

Yeah seems less likely that the user-agent is the problem. I read the man page, the default user-agent wget sends is "Wget/version". If cloudflare accepts "monkey poo" that suggests it must deliberately block wget, rather than using a whitelist of acceptable user-agents



A VPN certainly could be involved. The captcha challenge could have been triggered by using an IP associated with VPNs.

If I read Fenn's posts correctly he managed to retrieve the image, as a WebP, after completing the captcha challenge - if Cloudflare deals with troublesome IPs with temporary range bans, I'd still start looking elsewhere for the problem first (particularly javascript settings), but keep the VPN in mind.

It's very sloppy with that: --user-agent="wget" is fine, "Wget" is not. Likewise "GNU Wget" is not Ok but "GNU wget" is fine.
I tried that latter format because wget --version returns "GNU Wget 1.20.3"