Whisk and Cross-Origin Resource Sharing

Been using Whisk for about six months to prepare pages for a website and then uploading them. Love the app and my usage is fairly simple as I tag copy in html and then insert the URLs of images that have previously been uploaded to the website's server. Both words and images have been rendered in the right hand pane of the Whisk app… Until now. Logged onto the website in question and was asked to verify that I was human by Cloudflare, which was new. Now the images with their URLs are not rendered in the right hand pane of the Whisk app. I looked at the Developer Tools pane and the Console states that Whisk 'Cancelled load to [URL address of image] due to access control checks or that it failed to load resource because it violates the resource's Cross-Origin-Reference-Policy Response. And idea what's going on and how I can get round this in the Whisk app itself?

Perhaps the server is set to reject image requests if they're from web pages not on the server itself — which would include working on Whisk locally.

Here's an example…

My website is set to block “Hotlinking”, which might be a problem if I was working on a single Photics web page locally.

However, in the example, the broken image is using an absolute link. I normally avoid absolute links, preferring relative links…

Instead of https… blah blah blah …/images/the-image.png
I use a “root-relative URL”… /images/the-image.png

The paths are different on my website, as it's a WordPress setup, but that's the basic idea.

Even though WordPress will add the protocol and the domain part, I manually go in there and take that out. (Oh, and I still don't want to use the Gutenberg stuff.)

Is that a solution for you? I don't know. :man_shrugging:t2:
I'm just explaining how I do things. :smile:

I stopped using Whisk because Visual Studio Code has the “Live Preview“ plugin. But when I loaded up my recent Jigsaw Puzzle project in Whisk, it loaded right up — no problems! I was surprised, as I was expecting a problem. But, the image paths are all relative and all of the files were local. I could even play the game right in the Whisk Web Preview itself.

Note: With the Jigsaw puzzle, I put all of the images in the same directory as all of the other files. So, I only had to use the filename. Example… nasa-earth-blue-marble.jpg …no slashes, directories, domains, or protocols. So, it works nice and easy when local. And when the files are on the server, it's forced to use HTTPS — because that's how my server is setup to work.

However, when I reopened Whisk, I saw this…

I had to allow access to the main Jigsaw directory, otherwise many of the files would not load… JS, CSS, Images …even though the files were local. This seems to be a macOS security thing, as the Whisk app says…

Mac App Store applications are required to use a security technology called the App Sandbox. This restricts Whisk to only read and write files you have implicitly granted permission via opening, saving, or other operations like dragging/dropping.

Did you see a popup like that? :thinking:

Are you aware of the “File Access” section in the Settings / Preferences popup window?

I doubt that's the problem, but it's good to be aware of that part of Whisk.

Probably the server changed their configuration to disallow doing what you're doing... do you control the server? If so, you may be able to change the configuration. If it isn't your server, you may just need to download the resources and then use/serve them yourself (assuming valid copyright etc).

From the command line, you can call curl -I [https://url-here] and see what headers it give and see what the policy is. Chances are you are getting restrictions.

Thanks people. I've contacted the person who I think has control over the way the server is configured and await his reply. I am thinking that when I log into the website in question via Cloudflare, Cloudflare sends a cookie to the browser I am using to say everything is secure. But Whisk is not able to ask for a Cloudflare cookie and does not have anywhere to store one even if it could. If I get a workaround from the web administrator I'll post it here.

1 Like

The reason for the problem my end was that the site was being attacked by AI training bots, which were taking up 90 per cent up of the resources in its hosting environment and preventing people from accessing it. So the bots (and me) were blocked. The issue has now been resolved.

1 Like