What is best-practice way of consuming a SOAP web service in Firefox OS?
Are there any Firefox OS specific issues I should pay attention to or it comes down to a problem of consuming a web service from JavaScript (where I can use JQuery AJAX or similar)?
There shouldn't be any Firefox OS-specific issues - if/when you could make it work in a browser (preferably a Firefox browser, that is) then it should work just fine in Firefox OS, too.
Although one issue might arise, if the SOAP service doesn't serve CORS allow-origin headers, in which case your XMLHttpRequest would fail as the OS won't allow cross-origin XHR-s. You could overcome this by creating a Privileged application, that requests in the webapp manifest the SystemXHR permission, in which case you are allowed to make cross-origin requests to remote services, regardless of CORS headers.
Related
I have a Javascript application running in a browser, and I want to access some data sitting in a server that can't enable CORS.
It's not a testing application, is meant for the end-user, even if a little techy one.
I considered:
PHP Proxy: Not appropriate. Server on the other side make decision about IP geolocation.
Java/SilverLight: Unfortunately my #1 target is Chrome
JSON: Not available
What are my options?
Please notice that I'm not trying to make any malicious application: if the user need to approve or allow me to make this request is totally fine.
You are trying to do exactly what the Same Origin Policy is designed to prevent (and what CORS is designed to allow the server to permit).
Your options are:
Find a way to work with whomever controls the server
Get the users to download and install software which isn't subject to the Same Origin Policy (such as a stand-alone application or a browser extension).
You need to ask your users to install chrome extension to overcome CORS. I used to use it while developing ionic apps and testing on chrome
https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=en
https://chrome.google.com/webstore/detail/cors-toggle/omcncfnpmcabckcddookmnajignpffnh?hl=en
Team,
I am working on Angular JS application. When I want to test the app, I used to just launch the application directly into the browser from file system. The url would be like
file:///Users/easwar/AngularApp/index.html
When I need to launch the app in Chrome, I need to open the browser from terminal using the below command
open -a Google\ Chrome --args --disable-web-security -–allow-file-access-from-files
to avoid the below error.
"XMLHttpRequest cannot load , Cross origin requests are
only supported for protocol schemes: http, data, chrome,
chrome-extension, https, chrome-extension-resource."
But surprisingly in Safari the app works fine without doing anything like this.
I would like to find what is the difference between these browser behaviors? Why its working in Safari and its not working in Chrome without a tweak?
In short: google chrome doesn't like local cross calls.
More found here: Cross origin requests are only supported for HTTP but it's not cross-domain .
It's Googles privacy and security policy: they try to avoid as much risks as possible, and local file calling seems to be one of them.
Read more on cross origin requests and how they're handled in Google Chrome here: https://developer.chrome.com/extensions/xhr
If you don't want to use those console commands, you might want to look for a webserver to host it (or a local webserver).
I have an AngularJS/Cordova app which polls a JSON service on a remote server:
$http({method: 'GET', url: 'http://example.com/index.php'})
Developing in the browser and running off my intranet apache server (http://dev) I get "No 'Access-Control-Allow-Origin' header is present" so I fix this by adding:
Header set Access-Control-Allow-Origin "http://dev"
All works fine, and I see Origin:http://dev in my Chrome dev tools.
So, having to think about this for the first time, I wonder what the Origin will be when the app runs in the Android/iOS webviews. I decide to do a build and deploy on my devices and expect to see the same error in remote debugging (Safari for iOS and Weinre for Android), but to my surprise it works (without sending any CORS headers)! I also find that in both devices the app runs in the webview under the file:// scheme, rather than (what I assumed) a http server of some sorts provided by the phone OS.
So research seems to suggest that CORS is not required for file:// - such a "site' may access any XHR resource on any domain. But, when I test this on desktop browsers I find that while Safari does not need CORS for file:// but Chrome does, and FireFox works either way without CORS
So my questions:
1) why is my app working without CORS in Android/iOS - is it because CORS does not apply to file://, or, is Cordova doing something to make it work in the device?
I have <access origin="*"/> in my config
2) if, pending answers to Q1, I should want to be on the safe site and explicitly allow requests from apps, what value do you give Access-Control-Allow-Origin for file:// "hosts"? in my debugging there is no Origin header in the requests from file://
3) in addition to blocking the XHR request to the remote server, Chrome is also blocking my app templates (I'm using separate files), see below. Is this a potential issue with my app, or just a Chrome issue that I do not need to worry about?
XMLHttpRequest cannot load file:///Volumes/projects/phonegap/www/templates/tabs.html. Cross origin requests are only supported for HTTP.
There are two ways for CORS headers to signal that a cross-domain XHR should be allowed:
sending Access-Control-Allow-Origin: * (allow all hosts)
put the host you would like to allow into the Origin header by your backend
As for the file:// URLs they will produce a null Origin which can't be authorized via the second option (echo-back).
As mentioned:
Cross-domain policy does not apply to PhoneGap (for a variety of reasons, basically because your app is essentially running off the file:// URI on-device).
Please be aware that you will have to set up a whitelist for your apps to access these external domains.
As for the Chrome problem, which can be seen in the developer's console:
Failed to load resource: net::ERR_FILE_NOT_FOUND file:///C:/2.html
XMLHttpRequest cannot load file:///C:/2.html. Received an invalid response. Origin 'null' is therefore not allowed access.
there was a discussion on Chromium project's issue tracker, #40787. They mark the issues as won't fix as that behaviour is happening by design.
There is a workaround proposed to simply switch off CORS in Chrome for development purposes, starting chrome with --allow-file-access-from-files --disable-web-security
e.g. for Windows
`C:\Users\YOUR_USER\AppData\Local\Google\Chrome\Application\chrome.exe --allow-file-access-from-files --disable-web-security`
Here is some more cordova related answer:
CORS and phonegap apps
Domain whitelisting in Apache Cordova - a security model that controls access to outside domains.
Check these resources for more info on CORS:
Cross-Origin resource sharing and file://
A nice CORS tutorial: http://www.html5rocks.com/en/tutorials/cors/
Working around origin policy
HTTP access control (CORS) (Mozilla)
Check also Browser support for CORS:
http://caniuse.com/#feat=cors
And for the record formal CORS specification on W3C :)
I'm trying to create a web page that can connect to a client-local WebSocket server. The idea is to use the JavaScript client running in the browser as kind of a proxy to enable communication between the remote web server and the locally installed client application which implements the WebSocket service.
So basially, what I'd do is load a web page from https://example.com which includes some JavaScript that opens a new WebSocket to ws://localhost:1234/context.
This works fine as long as the web page is accessed via http. As soon as https is used, however, Firefox and Internet Explorer refuse to connect and the WebSocket constructor throws an exception (SecurityError, code 18).
Now, I already found advice from Mozilla stating that https sites should only use secure (wss://) WebSockets and plain http sites should only use plain WebSockets (link). But I don't really see the security issue when connecting to localhost from within an https context. Besides, this works like a charm for Chrome, Opera and Safari.
So the actual question is: Is there any way to work around this issue? Like introducing a non-https context inside the web page or something similar to get all browsers to connect to ws://localhost from within a https-delivered web page?
Thanks a lot in advance! I'm not exactly a web developer so this kind of browser-specific behaviour isn't really in my fields of expertise :)
You have to accept the cert first.
You can do this by simply going to https://localhost:1234/context, in your case. Once that's done, you can use the wss URL in your question.
I want to be able to detect if the browser support SNI - Server Name Indication. I'm hoping to redirect non compliant clients to a different address.
I was thinking of loading some content through SSL and make sure it was transfered securely. Otherwise the browser doesn't support SNI. Can this be done?
You could set up a server that supports SNI, serving two host names, on where you require SNI and one that's a fallback solution, both serving the name that they are hosting.
Something along the lines of:
https://www.example.com/name returns a representation saying I'm www.example.com
https://www.example.net/name returns I'm www.example.net (and requires SNI).
If you make an XHR request to https://www.example.net/name and it returns www.example.com, then the browser doesn't support SNI.
Not sure if this is what want but there is this
RewriteEngine on
# Test if SNI will work and if not redirect to too old browser page
RewriteCond %{HTTPS} on
RewriteCond %{SSL:SSL_TLS_SNI} =""
RewriteRule ^ http://www.example.com/too-old-browser [L,R=307]
If an old browser tried to use a site which needs SNI then it will be redirected (in this case back to http and a page saying browser is too old). But you will always get an error. It can't be avoided. The browser says hello IP...., and apache replies hello here is my certificate. If the browser does not supply SNI in the hello apache just sends default (i.e. wrong) certificate. Browser then complains.
If you want to pick this up from http before swapping to https then you could put something like this in htaccess
#Set $_SERVER['SSL_TLS_SNI'] for php = %{SSL:SSL_TLS_SNI} or value
SetEnv SSL_TLS_SNI %{SSL:SSL_TLS_SNI}
And then in your page do a https fetch from the default domain (default so browser does not say there is a security error). If SNI is working the in php $_SERVER['SSL_TLS_SNI'] will have the domain name, otherwise it will have %{SSL:SSL_TLS_SNI}. This bit of code could be improved but you get the idea.
You can only test for SNI support prior to requiring it. That is, you cannot force users onto SNI HTTPS and then fall-back if they don't support it, because they will receive an error like this (from Chrome on Windows XP) with no way to proceed.
So (unfortunately) the user has to actually begin over an insecure HTTP connection and then be upgraded only if they support SNI.
You can detect SNI support via:
Remote script
From your plain HTTP page, load a <script> from your destination SNI HTTPS server and if the script loads and runs correctly, you know the browser supports SNI.
Cross-Domain AJAX (CORS)
Similar to option 1, you could try performing a cross-domain AJAX request from the HTTP page to the HTTPS, but be aware that CORS has only limited browser support.
Sniff the user-agent
This is probably the least reliable method, and you will need to decide between having a blacklist of browsers (and operating systems) known not to support it, or a whitelist of known systems that do.
We know that all versions of IE, Chrome & Opera on Windows XP and below do not support SNI. See CanIUse.com for full list of supported browsers.
Since commercerack upgraded to SNI for all sites we've had the same issue. (Users starting checkout and getting a nasty SSL issue).
Feel free to use this as a starting point.
As the list of browsers grow I will update but it does IE on XP + Android 2.0-2.2 right now.
https://github.com/brianhorakh/html-sni-useragent-sniffer-warning