I've made a small gwt app and released it, but today I found a serious problem. I was aware of the same origin policy issue so I've put my gwt app and rest json app on the same server. But apparently browsers doesn't regard http://www.xyz.com and http://xyz.com as the same source so when a user lands on a www.xyz.com he can't get data from http://xyz.com.
This is the message:
XMLHttpRequest cannot load http://xyz.com/backend/...
Origin http://www.xyz.com is not allowed by Access-Control-Allow-Origin.
What is the best way to deal with this? I've googled and first found .htaccess solution which doesn't work for tomcat. I ended up using a empty landing page index.html with only redirect to url without www in it. It's not the best solution because someone can still type in url with www which is not going to index page so it wont get redirected.
Any help will be appreciated.
You shouldn't use absolute URLs in your app unless absolutely necessary.
I.e. you should have "http://example.com" in your code if the app can be loaded from http://www.example.com.
For instance, if you want to load some data from, e.g. http://example.com/abc/def, then put "/abc/def" in your code, not "http://example.com/abc/def". That way, the browser will resolve the URL to either http://www.example.com/abc/def if the app has been loaded from http://www.example.com, or to http://example.com/abc/def if it's been loaded from http://example.com. And you never risk to hit the Same-Origin Policy.
You should only host a website under a single sub/domain. All traffic to http://www.example.com should be redirected to http://example.com or vice versa.
Related
I am calling a rest API from Https deployed Application
to Http Rest API.
I have written the logic in JavaScript by using Angular Js framework.
The web service call got failed with the below message.
The page at 'https://********someurl****' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint
Requesting if any one can help me get out of this error.
Workaround:
1- Click the shield icon in the far right of the address bar.
Allow mixed content in Google Chrome
2- In the pop-up window, click "Load anyway" or "Load unsafe script".
If you want to set your Chrome browser to ALWAYS(in all webpages) allow mixed content:
1- Close Chrome. Chrome must be fully closed before the next steps.
2- Right-click the Google Chrome desktop icon (or Start Menu link). Select Properties.
3- At the end of the existing information in the Target field, add: " --allow-running-insecure-content" (There is a space before the first dash.)
4- Click OK.
5- Open Chrome and try to launch the content that was blocked earlier. It should work now.
This is just workaround and you need to solve by securing both app and rest api.
Use an https endpoint for your Rest API, otherwise you will end up with mixed content
HTTPS is important to protect both your site and your users from attack.
Mixed content degrades the security and user experience of your HTTPS site.
If you are unable to switch to https, another solution is to set up a server side end point which you access via https, which then makes the call to the http url and returns the result. In other words, making your own little HTTPS proxy to the http resource
In my case chrome was causing the issue, don't know why, other browsers work fine.
**Tip: I wasted two days trying to find out the cause, hope this will help someone.
I am trying to load socket.io using the following code:
<script src="http://cdn.socket.io/socket.io-1.4.5.js"></script>
However some users have reported the following error to me:
Failed to load https://cdn.socket.io/socket.io-1.4.5.js ERR_SSL_PROTOCOL_ERROR
Is this an automatic security setting on modern browsers? And if so can it be disabled?
The problem is not your fault!
Accessing that link in my browser fails as well, and inspecting the unsuccessful request shows that the following header was set:
Upgrade-Insecure-Requests: 1
This tells the browser to "upgrade" all http:// URLs to https://, which seems to mirror the error your users are reporting.
ERR_SSL_PROTOCOL_ERROR indicates that the SSL certificate for https://cdn.socket.io/ is incorrectly configured and thus the browser (rightly) assumes the worst, and chooses not to trust data served from that domain over the secure protocol. When the domain is configured to "upgrade" insecure requests to secure ones, and secure requests are rejected by the browser, it becomes clear why there is no way to access the content correctly at either URL.
I would contact the administrators of the website and inform them of the problem, or just simply switch to another CDN like Chris Chen suggested:
<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.4.5/socket.io.min.js"></script>
Sounds like the users who are experiencing that error are hitting the https version of your page. Best way to deal with this issue is by changing your code to:
<script src="//cdn.socket.io/socket.io-1.4.5.js"></script>
Or
<script src="https://cdn.socket.io/socket.io-1.4.5.js"></script>
The former is preferable (because it is faster for http users) unless you are working with an .html or .htm page and want to open it without a web server.
The link is not working at all from anywhere. Is it a private link that require certification?
If you just want socket.io.js, use link from https://cdnjs.com/libraries/socket.io
I recently set my appname.appcache contents to this:CACHE MANIFEST
# 2010-02-10 v1
CACHE:
index.html
test1.html
test2.html
# many more project root html files
#stylesheets
css/main.css
css/normalize.css
css/themes2/jquery.mobile-1.0.min.css
#gameMessages
some-folder/name.html
#many more like this
#js
js/vendor/jquery.mobile-1.0.1.min.js
# a few more files
Now when I navigate to index.html I get an error in google-chrome:
Failed to load resource: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. file:///home/username/Desktop/project-name/test1.html
XMLHttpRequest cannot load file:///home/user-name/Desktop/project-name/test1.html. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
In phonegap's config.xml file:
<access origin="*"/>
So does this solve the problem when run on real mobile devices. And why am I getting this error just on Chrome. On Firefox it runs fine, by asking for a permission to store files.
And does appCache improve performance for application built with phonegap?. Does Caching resources already available on hardware make things faster? I know that content on cache than those on HD are processed really quick. Hence the appCache facility is used in this case.
I had also get the same error, but in my case it was due to the fact that i was running my file on http and caching resources which were on https therefore not on the same origin.
If you have that kind of issue you can look into it.
Not really an answer but thanks for pointing me in the right direction in solving my own problem. (posted here in case it ever helps someone with a similar issue - I tried adding just a comment but the text is too long)
I'd been using a cache manifest for the web version of an app I'm building but hadn't considered it for the PhoneGap build. When you ask "does appCache improve performance for application built with phonegap?" for me at least, the resounding answer is a big yes.
I'm using magnificPopup loading ajax type pop-ups, all worked fine (even when the phone/device is offline) except for when the popup content includes a RoyalSlider gallery - these successfully load the ajax content (I can tell thanks to magnificPopup's very useful ajax callbacks) but they don't go on to add this to the DOM. I still have no idea exactly why that is, I'm guessing the problem is somewhere in RoyalSlider's code, perhaps looking for a resource it considers to be online? But anyways, implementing a cache manifest has completely solved the problem for me. Thanks.
Hi I have used the http://whateverorigin.org/ origin to get content from other domain and display it on my domain.
The issue is my page uses https:// but (http://whateverorigin.org/) supports only http://.
If I change the url to https://whateverorigin.org/ the iFrame never loads the content.
So how do I overcome this problem, Any suggestions are greatly appreciated.
The code:
var url = 'https://www.otherdomain.com/001003227.htm';
$.getJSON('https://whateverorigin.org/get?url=' +
encodeURIComponent(url) + '&callback=?', function(data){
DO NOT DO IT. Http Content within a HTTPS page is inherently insecure. Point. This is why IE shows a warning. Getting rid of the warning is a stupid hogwash approach.
Instead, a HTTPS page should only have HTTPS content. Make sure the content can be loaded via HTTPS, too, and reference it via https if the page is loaded via https. For external content this will mean loading and caching the elements locally so that they are available via https - sure. No way around that, sadly.
According to an issue on GitHub you can do the following:
I recommend using the following path if HTTPS is an requirement:
https://whateverorigin.herokuapp.com/get?url=...
Trying to access the main page with HTTPS will not work due to how the certificate is setup.
I've tested this on my own site and it works.
I am using the following JQuery plugin to load an image slider http://www.orionseven.com/imageloader/index.php
However this is on a secure page (https) although the images are from external urls so therefore are not on secure pages. Is there anyway I can stop IE 7 displaying the security warning? Maybe changing my code or something?
You cannot disable those warnings.
The reason you're seing them is because the user should be notified that non-secure requests are being made (and potentially compromising the security in the process). Turning them off would be bad for the user.
You should probably be hosting the images on your local server rather than expecting a third party to host them for you. That way they can all be served as HTTPS from the same site, and problem solved.
If you must fetch them from the third party server, you'll only be able to solve this issue if that third party also provides HTTPS on their server. In that case, you'd need to modify the URL used to request the images to change the protocol depending on what protocol the main page is being served with.
If you want to load them remotely and that remote server doesn't provide HTTPS, then you cannot get rid of the message -- it's there intentionally in IE to provide a legitimate security warning. You can't override it.
I have the exact same issue. Since M$ considers every single one of their users to be brain-dead and decided to lock-down the ability to bypass that warning, I've decided on a much simpler solution- Use literally any other browser. Check out this solution-
https://stackoverflow.com/a/23047482/3692082
You could proxy images through localy hosted php script.
https://server/image.php?url=foobar.com/foo.gif
<?php
echo file_get_contents("http://".$_GET['url']);
?>
some comments about cross-site-scripting vulnerability should follow:)