I am facing an issue with my hosted project.
The request with link :- http://......./api_tester.html works fine and
provides results, but, it gives CORS 'Access-Control-Allow-Origin' Missing
when the api_tester.html file is accessed via the browser directly.
The URL for the file in the browser is file:///E:/workspace_windows/api_tester.html
Kindly suggest.
It seems you are trying to open the file directly from desktop, hence it is picking its protocol file:// protocol. Use either complete url starting with HTTP or run from any web server. Secondly error you stated means you are trying to access the page hosted on another domain and this usually happens when you do XHR requests to domain other than the one where your file is hosted.
You can add header "ACCESS-CONTROL-ALLOW-ORIGIN" to the file you are trying to access to allow all requests to be accessible from all different domains.
Related
Access to audio at 'https://.amazonaws.com/.mp3' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource
We have a vue.js frontend and spring boot backend.
There a tag in a vue.js file which gets the src link by calling spring boot backend server. The backend returns the src link.
As you can see the below is the run time audio component
<audio data-v-3f267e7a="" src="https://****.amazonaws.com/****.mp3" eq-attached="true"></audio>
I am confused as why the browser is throwing CORS error in this case. Please let me know why the error in the first place and how to solve this. CORS is already enabled in spring security file. I already tried with #CrossOrigin annotations in spring controller.
Since your error is CORS, between your vue.js and amazon audio url, spring boot is not related to that.
Commonly CORS said us: No web application can download my resources using javascript.
In your case, amazon is telling you: Your web at localhost cannot download my audios.
If you would be the owner of amazon, and you want any website to be able to download your audios, you just need to add this response header in the audio url:
Access-Control-Allow-Origin : *
How fix it?
Try to use a minimal ajax invocation to dowload the audio url. With this you can verify if url is "downloadable" or has the classic cors headers. Don't forget to test it with a kind of server like one of these
If you can't download it or you get the same cors error as your vue app, you could verify that amazon does not allow this type of usage of audio urls.
Also verify if amazon has a kind of administration web console which allows us the registration of origins. In this case you must add the localhost:8080 or any domain in which your web app is running.
Workaround
If the url is downloadable at backend side, I mean with java and not with javascript, you could create a simple spring controller which will download the audio and return maybe the bytes or another format that your vue app needs. At this point you are the owner, so you could add any CORS header you need.
Cannot work with firebase projects locally (I guess after Chrome auto-update). I guess it's not firebase related but Google services in general.
I get CORS error despite the fact I don't use it. CORS extension is disabled.
Error: https://securetoken.googleapis.com/v1/token?key=AIzaSyB2rVH5oURUwciXasOeGlTNW7Lye6naCn0: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://localhost:3000' that is not equal to the supplied origin. Origin 'http://localhost:3000' is therefore not allowed access.
I have tested Safari and it works, so the issue is Chrome related
I'm not an expert on this topic, but as far as I understand Chrome restricted http stuff even more.
I couldn't use https://localhost:3000 as there was no https server
I run webpack server for my js code and I've found solution to set HTTPS=true environment variable and it will enable the https option in webpack dev server.
Chrome doesn't respect such SSL certificate, but if you click Advanced -> Proceed then everything works and I don't get CORS issue any longer.
It may be a better option to generate some SSL certificate that Chrome respects so that you don't have to click Advanced -> Proceed every time, but I'm good with this for now as I can continue working on my projects.
We're using the HTML5 Application Cache feature:
<html manifest=".appcache">
...
</html>
When returning users navigate to this application they will already have all static files cached and the application is therefore loaded without network requests.
Once the application is loaded it will make AJAX requests to load dynamic content, and the browser will check whether the Application Cache manifest is outdated and possibly download a new version of the application in the background.
Many of our users are accessing this application over insecure connections (HTTP, not HTTPS).
We're in the process of introducing HTTP Strict Transport Security (HSTS) on the servers that host the application.
Implementing HSTS means that our servers will handle requests like this:
If the request is insecure (HTTP only), then the server will respond with HTTP status 301 and a Location header that redirect to the requested URI but changing scheme to https.
Otherwise; if the request is secure (HTTPS) the server will process it as normal but decorate the response with a Strict-Transport-Security header.
So, when a new user open up our application over HTTP they will be redirected to HTTPS instead and then the application cache manifest is installed using the secure location. That's perfect.
However, a returning user (over HTTP) will NOT be redirected to the secure location (because they already have a cached version on the insecure location). The application cache manifest won't load (since it's a redirection). So returning users are stuck with the application version they had cached and they're stuck using HTTP which is no longer allowed. This is very bad.
We need to come up with a way to transition returning HTTP users to the HTTPS version. How would be best do that?
The way I see it there are two problems:
The browser cannot fetch the application manifest (because it is a redirection). It is therefore unable to upgrade the application to a new version.
We could perhaps overcome this problem by configuring our servers to allow /.appcache to be served over plain HTTP.
Even if we do that, the application will still be accessed at the HTTP location (since that what's cached by the manifest)
To workaround that, we might have to implement some kind of javascript logic that changes the scheme of document.location.href to HTTPS.
I don't like this approach, but it's the only one we've got at this point.
We settled on the following solution to this problem:
When server receive an insecure request to get the application cache manifest (/.appcache in our case), then a 404 response is returned instead of the normal HTTPS redirect (301).
Getting a 404 causes the cached manifest to be stale and the browser will therefore attempt to reload the application on the next refresh, which will cause it to fetch index.html and be redirected to the secure location.
I'm getting the errors when testing my application locally since I switched to https:
Warning: Domain www.example.com does not specify a meta-policy.
Applying default meta-policy 'master-only'. This configuration is
deprecated. See http://www.adobe.com/go/strict_policy_files to fix
this problem.
Error: Request for resource at
https://www.example.com/?json=user/get_logged_in_user by requestor
from http://localhost:8888/Test-debug/Test.swf is denied due to lack
of policy file permissions.
I tried changing my localhost to https but got the following error:
Secure Connection Failed
An error occurred during a connection to localhost:8888. SSL received
a record that exceeded the maximum permissible length. Error code:
SSL_ERROR_RX_RECORD_TOO_LONG
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
From what I've read I can upload and add a policy file and changing secure to true but I don't want to allow calls from anywhere. Once the swf is on my server everything works fine.
Is there a way to get this to work locally for testing? Is there something that I can enable while testing like:
Security.allowDomain("localhost");
Or do I have to upload a cross domain policy and then delete that policy when I'm done testing?
Since my local site is running locally in the browser shouldn't it be able to make a connection to a https connection?
Using of https (btw it does not configured properly according to message you posted (did you use FireFox to test?)) will not help. The problem is that www.example.com does not have crossdomain.xml policy file, so flash player does not allow to access that domain from your localhots which is also a domain.
If you have an access to www.example.com add policy file here with wildcard access, if not - test via http is possible only with mocking response with some http proxy.
I changed to testing using file:// (no server) and it works making https calls.
I enabled SSL on my website which is hosted on Blogspot with a custom domain and I encounter this error in console which asks me to Load Unsafe Scripts on the address bar.
What I see in Inspect Element:
This has nothing to do with IPv4. The error just says that, while your page was served over https, it's trying to load an external script via http, which Chrome doesn't allow. You must modify your page to load all resources over https.