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.
Related
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
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 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.
I'm using Advanced REST Client to test external API which requires me to specify
Connection: Keep-Alive. The connection fails (NO RESPONSE) and inspecting Chrome console I noticed Refused to set unsafe header "Connection" followed by net::ERR_INSECURE_RESPONSE
Is there any Chrome settings that allow me to override this? BTW, the API works when I use external tools like APIGee. I've tried Chrome CORS extension (Allow Control Allow Origin) but still unsuccessful.
The issue is that chrome is refusing to load a resource that has an invalid or expired SSL certificate. Even if you could get it to bypass that it would be a bad idea as it would make man in the middle attacks easier in your application.
My suggestion would be (if you trust the server or if it's running locally) to import that certificate to your store so it's trusted in your development environment. If the cert is expired and it's hosted locally look at the documentation on how to change the certificate or to add a self signed one (which you then also would add to your trusted sites)
How to add a self signed very to your store
For Mac
For windows
You'll have to restart chrome for it to see the certs in the store after doing this
Again, be sure you trust these certs origin as they'll be considered trusted as if a legit CA HAD issued them
I have a html application that sends an AJAX request to a Qt C++ HTTP Server on my local computer (hosted at "https://localhost:8081") but the AJAX request seems to fail due to host name mismatch issue. My question is "Are there any possible solutions that will allow me use my wild card certificate usable in my Qt Application" or is there any way that I could redirect all requests to a certain domain (valid for my certificate) to a localhost URL in my machine?
Thanks in advance.
Finally had this problem solved.
This link is a good start for people who will have the same problem:
http://www.codeproject.com/Articles/1463/Using-http-www-yourname-com-instead-of-http-localh