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.
Related
I keep getting the error below ONLY on Chrome Browser, however there is single call to http://fonts.gstatic.com/s/roboto/* within the page nor its included statics files. I do not have any idea why Chrome makes this call nor where it is coming from. Access same url from any other browser works except Chrome.
Please I will appreciate your help on fixing this error
Mixed Content: The page at 'https://www.domainname.com/' was loaded
over HTTPS, but requested an insecure font
'http://fonts.gstatic.com/s/roboto/v18/KFOmCnqEu92Fr1Mu5mxKOzY.woff2'.
This request has been blocked; the content must be served over HTTPS.
Just for the record and anyone that might be facing similar problem. As #Raj mentioned in his answer, Chrome does not let https sites use resources from http sites.
However, I narrowed down issue when I served an empty page with just HTML & Body tag and confirmed the issue still persisted. This tells me there might be something else wrong somewhere.
And it happened to be one of the installed Chrome Extensions that is injecting this fond resource. I fixed the issue by disabling all Extensions. I will figure out which one was doing the harm by re-enabling them one after another
Chrome does not let https sites use resources from http sites. Changing to https://fonts.gstatic.com/s/roboto/v18/KFOmCnqEu92Fr1Mu5mxKOzY.woff2 will solve the problem
I had the same problem. The solution was to deactivate a chrome plugin. In my case, it was VLC Video downloader, which inserted this path to an unsecure resource.
i have a small problem by using HTTPS. By using SSL in my Rails-Application Chrome shows me the following error-message:
The page at 'https://www.thesitename.de/shop/counter/checkout/cart' was loaded over HTTPS, but displayed insecure content from 'http://www.thesitename.de/assets/jquery-1.10.0.min.map': this content should also be loaded over HTTPS.
Does that mean that the jquery-file is not loaded via HTTPS or that some requests in the jquery-script are over HTTP? In the sourcecode of the Site i don't see any HTTP-Javascript-includes. The jquery-File is local stored.
I hope this is enough information and someone can help me.
Thanks!
The file being requested forms the sourcemap for jQuery. This can be used by some browsers to help with debugging.
It's referenced in the download documentation here: http://jquery.com/download/
When looking at the problem elsewhere on stackoverflow I came across this:
sourceMappingURL from jquery generates 404 error in apache
There may be useful info in there.
My advice would be to try the following:
Remove the line from your jQuery library (this means that you won't have access to the sourcemap when you're debugging - which may not be a problem for you)
Use a CDN to source your jQuery libraries instead - both jQuery and Google have ones.
Try downloading a local copy of jquery-1.10.0.min.map beside your version of the jQuery distribution.
Hopefully one of the above should resolve your issue.
One of the Javascript files we use in a website is reporting a 403 error when we try to request it from googlecode.com.
http://tab-slide-out.googlecode.com/files/jquery.tabSlideOut.v1.3.js
Failed to load resource: the server responded with a status of 403 (Forbidden)
This has previously been working without any problems for many months.
The problem is inconsistent in that it seems to work in my office but if I log on to an external machine it returns the 403. This may be down to caching so I'm not focusing too much on that.
Does anybody have any ideas how this might have happened? It's quite worrying that code hosted externally can suddenly be inaccessible!
It seems working at my end as well.
You may track the URL requested using firebug.
or
Please provide the URL of webpage in which you are accessing JS file because sometimes cross site scripting is the reason.
Thanks,
Krishan
Alan, I had to find another source for the .js file. I downloaded it from the page below and referenced it from within my site. The file I found is under the Android section of code.google.com, but it appears to be working fine:
http://code.google.com/p/androidoc/downloads/detail?name=jquery.tabSlideOut.v1.3.js&can=2&q=
Vince
I have a script done by myself that uses jQuery Ajax functions to log some data from a web page when I access it. It takes some info and sends it to my local Apache host to save in a text file.
It worked for months, but I now getting an error related with this Same-Origin Policy(I know how it works and its purpose) and the browser is now ending the script execution showing this message:
The page at https://www.website.com/ displayed insecure content from
http://127.0.0.1:8081/whatever.php
Followed by this:
Refused to connect to connect 'http://127.0.0.1:8081/whatever.php?arguments=1' because it
violates the following Content Security Policy directive: "connect-src
https://www.website.com/* https://*.website.com/
https://*.website.net xhr: error: SECURITY_ERR: DOM Exception 18
That last domain is colored in red on the error message. A curious detail is that on the JavaScript code on Tampermonkey I have the #includes of those domains but not the red marked domain. I've added it and tested, but didn't work.
Every discussion I've found on Google tells how to disable this policy but in case that you're developing an extension, that is not my case.
This code will just run in my machine, I didn't have the intention to distribute it in any way so any solution will be appreciated, even if the solution is to change browser configuration directly.
If this' useful, I'm using Windows 7.
Tampermonkey Beta fixed its GM_xmlHttpRequest to be independent from the page's CSP.
Unfortunately it can not fix jQuery AJAX requests cause it doesn't have a clue what sites are going to be contacted.
If the page you're contacting is Facebook, then the CSP is sent only to Chrome 21-23, but not Chrome 24. So you can use Tampermonkey's #user-agent tag to simulate Chrome 24.
On your local server, the whatever.php you're sending the data to, set up CORS (ie. send header Access-Control-Allow-Origin: *).
You do not need anything from above. All you have to do in your ajax call is to add
script.php?callback=?&your_parametars_here
and in php file you just have to add this when retrieving data:
echo $_GET['callback'].$your_data_here
thats all!
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.