We are doing a simple GET on a REST service which we are not the owner, and so we can not change anything there, and also we asked already the maintainer to change their behavior but they wan’t do it.
The GET on the android device where we also use the cordova-plugin-crosswalk-webview are adding the header “Origin: file://” which is not working for the service. They are checking the origin header. So there is no problem with CORS but it isn’t working anyway.
We googled and found out we are not the only one which has this problem, and probably there would be a solution for it.
Can you help figure out a solution for it? We probably need to remove the Origin header on devices.
Seems to be the same result, I already tested it half an hour ago.
So to be clear, this is not a CORS problem, the problem is, adding this “wrong” header will fail the request. Often services will check for right the same header or no header, and not allow an origin header like file://
There are other people and other posts which has the same problem, like that
If we do ionic cordova emulate android or ionic cordova run android the headers for the post shown in dev tools and obviously on server side are this
And as you can see the Origin header is set to file://
And this is the problem, many many many servers doesn’t accept **Origin file://*` because this is a real world security problem for example on email hijacking!
BTW: And that’s the reason why we tried to use IonicNative HTTP where we can not send a json message
Please edit your post, it is not very readable at the moment.
Use the </> button above the input field to format your code, command line output or error message (select the text first, then click the button or wrap it in ``` manually). Check the preview if it looks better. This will make sure your text is readable and if it recognizes the programming language it also automatically adds code syntax highlighting. Thanks.
Yeah, that is kind of relevant information to understand what you are talking about here. That is also requesting a file, so…
Thanks for posting the additional information. Now I know what you are talking about.
The thing is, this Origin is actually correct. The app is running as file:// (not //file as you wrote in your topic title) on the device.
Good APIs have a configuration option to define the allowed origins for an API key.
What is the Origin when you use ionic serve?
So this is identical for both iOS and Android?
If this would be configurable somewhere, and I honestly doubt it, it would be a configuration option of the WebView.
Can you elaborate on that please?
Where you can’T send a json message I replied there and am waiting for an answer.
Sorry I know how to format a post with style code and so, I’m doing 10 things contemporary and I forgot it, so sorry.
Naturally they can define the allowed origins, but many of them wan’t allow a Origin: file:// because as I mentioned before, this is a really big security issue. For example on emails and others!
So we know we have 0 possibility to persuade them to do this.
We googled many many days it seems there is no possibility to find a solution for WebView neither for crosswlak webview (which in meantime is “deprecated”).
Honestly I think there would be more maintainer which doesn’t support origin file:// then which does.
You can configure your webserver which schema and origin you allow. Many maintainers of a Service don’t allow a schema different from http/s so file:// data:// or others wan’t work. And this for security reasons!
What is the Origin when you use ionic serve?
ionic serve which are using the browser adds as any browser the origin of the dev page, in ionic default case Origin localhost:8001, but this is no problem because in dev we can use a simple node proxy. (I already and discussed with you the abbility to remove the origin from ionic dev proxy, time ago)
running it on Android emulator and Android device with ionic cordova emulate|run android the app is running in Android System WebView which is the reason for the Origin: file:// header.
I can not check it for now on IOS because I’m developing firstly on Ubuntu and so on Android device, we have to build later and test it later for ios.
Again, what are the security problems of file://? I know it is more uncommon as most websites aren’t executed in a file context, but for now you only parrot the same thing over and over again and didn’t give me any supporting argument or even evidence on this. (Not strictly relevant to your issue of course, but as you repeat that I want tot know).
Ok so even outside a Webview context, with a normal browser, this header is added to the request.
So this is clearly a browser feature.
Means there is an RFC for that: RFC 6454 - The Web Origin Concept
Unfortunately it doesn’t say anything if a browser may change it.
One possible out could be this:
Whenever a user agent issues an HTTP request from a “privacy-
sensitive” context, the user agent MUST send the value “null” in the
Origin header field.
Does your API accept null values or does it have a whitelist?
If it does accept, one could research if one can trigger this somehow.
Why don’t you use that in production or for the mobile apps as well?
Sujan, I believe the problem with accepting an origin of “file://” if your server’s CORS implementation did accept it (my IIS test did not using the out of the box CORs configuration, or at least did not set the httponly session cookies) is that it is almost the same as accepting an origin of “*” (i.e. any origin). The problem with this should be clear if you have a good understanding of CORS and why it is important. If not, suppose you went to your financial institution and logged in. Then you go to the fictitious web site badactor.com, which automatically executed AJAX requests instructing every bank to transfer the balance of the account to the hackers account. Banks that you were not logged into or that had solid CORS policies would be protected. But if your bank accepted CORs requests from anywhere, when badactor.com’s javascript hit your bank, your account would be drained. Accepting an origin of file:// where cookes could be set would in theory be a little less dangerous than this, but still effectively have the same type of vulnerability. Basically if someone could be convinced to enter there credentials in a web page reporting file:// as the origin and then they ran another web page in the same “browser” (sharing the same cookie pool) that also reported file:// as the origin, the attack would be the same.
I am still learning all of the ins and outs of this as I evaluate solutions that have the minimal attack surfaces exposed (httponly cookies/tight to no CORS configuration). So if I missed something, please let me know. But overall I think a CORS configuration accepting file:// from your web server would be very dangerous if you would also not allow any origin.
Did you get any solution for this. I am too facing same issue.
While I making request to payment gateway from android app, the payment gateway refuse the request because the origin header goes as Origin : file// in case of android.
I am using Ionic version 1. Please help me if any one get any solution for this.
Here is my code.
First opening browser using InAppBrowser puigin.
var openInAppBrowser = function(fieldDevice) { alert('running in android.');
window.localStorage.setItem('transParams', fieldDevice);
//Post all required paremeters to the payu
iabRef = window.open('epayDevice.html', '_self', 'location=no');
Then in epayDevice.html submit for with required parameters as.