Actually, some cross-domain request are honored, such as for scripts and images. But, apparently calls for mp3 files are not allowed, even with an entry in .htaccess. Or am I missing something?
Every cross-domain request is blocked by CORS.
If you are iFraming something, that’s different.
4 Likes
A mystery then. Look at pktest.000.pe and see the scripts that get loaded from a totally different domain – no iFrames involved.
That is a bit weird, yeah. Three things could be happening:
-
I am an idiot and forgot a part of the rule
-
Something changed
-
There is bug in the system that is allowing this to happen
I made this public so maybe someone else will stop by and share their opinion
3 Likes
Two words: google-analytics.com. Or was that 3 words. Many large commercial sites rely on loading files (js, axd, etc.) from other domains.
I’m thinking that mp3 files don’t cross-domain load because of music copyrights? It would be nice if there was a list of file types that are cross-loadable.
Huh, this is weird and shouldn’t be possible I think. My money is on option #3. For some reason it seems that some URLs are accessible without the test cookie, and I can’t think of any reason why that would be desired behavior.
3 Likes
According to chat-gpt4:
“MP3 files are not inherently blocked by CORS; whether they can be accessed depends on the server’s CORS configuration. If a server is set up to allow cross-origin requests and includes the appropriate CORS headers (such as Access-Control-Allow-Origin), then MP3 files can be accessed from a different domain.
If the server does not include the necessary CORS headers, browsers will block the request to the MP3 file when it is requested from a different origin. Therefore, the ability to access MP3 files via cross-domain requests is contingent upon the server’s CORS policy rather than the file type itself.”
Is Apache configured to support my sites with an Access-control-Allow-Origin “*” statement in a .htaccess file?
Again, all files are meant to be blocked from cross-origin requests. As to why some are and some are not, we’re not sure right now.
3 Likes
I’m not sure I understand: All files should be blocked by CORS?
Just of fun, I “inspected” what gets loaded in www.wunderground.com, a well-known weather site. A bunch of files are getting loaded from cross-origins; here are some examples:
fonts.gstatic.com
assets.adombedtm.com
sum.instama.io
resources.digital-cloud-west.medallia.com
s.ws-x.co
sb.scorecardresearch.com
fonts.googlekapis.com
How is this possible? This appears to be a common practice in the WWW.
So I am totally confused, can you enlighten me?
No, only requests to other domains that are on free hosting are blocked.
So a request to gstatic.com is allowed, but a request to mysite.epizy.com is not.
You can bypass this restriction by using Cloudflare, however that only works if you have a custom domain
4 Likes
Thanks for clearing that up for me! I’ll move my NS to CloudFlare for my custom domains. (Although I don’t know why a different NS matters – maybe that should be a separate discussion.)
The difference is not nameservers, it’s Cloudflare’s proxy.
The reason CORS doesn’t work is because our browser validation system blocks it. This system is mandatory on all sites UNLESS the traffic is coming through Cloudflare’s proxy, in which case it’s disabled because Cloudflare provides sufficient protection for your website.
Changing Cloudflare’s nameservers is not what fixes it, but using Cloudflare’s proxy is. And to use Cloudflare’s proxy, you need to use Cloudflare’s nameservers.
4 Likes
Thanks for the explanations. I’ve implemented CloudFlare and with some experimenting, everything works as desired! I did have some confusion trying to follow “A Full Guide to CloudFlare” as there panels are slightly different now.
Thanks again for your help!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.