Support for Android 4.4 and later

[mburger81]

Hi, we are developing a cordova app which has to use a Websocket Service deployed by a 3rd part on cloud, this service for security reason is checking the origin header.
Using native WebSockets on Android 4.4 in WebView is setting always the origin header "file://".
We didn't found until now any solution to remove this header on android.
But we found your cordova plugin where we can set the header and remove them, this is working because you are using jettys WebsocketClient instead of native Websockts, but as you write on your readme from 4.4 this plugin is not used anymore.

So I would like to aks you two things:

1. Do you have more experience using WebSockets and Cordova plugins, do you think there is a way to remove this header with a cordova plugin, for example intercepting the request from SystemWebView and remove the origin or something else?
2. If first does not work, do you thinkg we can use your plugin also on KitKat until Android 7.x.x

Thx a lot for your help and time

[knowledgecode]

This plugin is able to enable with using an override option even Android 4.4 and later. For example you can rewrite the Origin request header like this:

WebSocket.pluginOptions = {
    origin: 'http://example.com',
    override: true
};

var ws = new WebSocket('ws://echo.websocket.org');

However, checking the Origin for security purposes doesn't have any meaning because we can rewrite it freely in this way.

[mburger81]

Good to know!! One last question.
We can use always WebSocket like a HTML5 Websocket, right? But under the hood on android your plugin is using your native WebSocket instead of the HTML5 Websocket right? And only in this case WebSocket.pluginOptions does make sense.
Im a little bit confused, because you wrote
"This plugin is able to enalbe with using an override option even Android 4.4 and later." But in your readme you write on Android 4.4 and later the plugin is not used as default.
So to use your pluginOptions should we override (and if yes how) this default behavior and use always your implementation, or this this pluginOptions also set the right origin under the hood in the WebView request?
Thx very much for your help!

Edit:
Ok I saw this in your readme This plugin has the following options. All these parameters are optional. Of course these don't affect built-in WebSocket.. So probably we have to get work the plugin also as default on Android 4.4 and later. right?
Edit2:
Looking to this piece of code

if (!WebSocket.pluginOptions.override && BuiltinWebSocket) {
                return new (BuiltinWebSocket.bind.apply(BuiltinWebSocket, [].concat(this, Array.prototype.slice.call(arguments))))();
            }

pluginOptions.override does this out of the box :) also I see the documentation of override just right now!

So okay sorry for that. 👍

Can you estimate how much slower is the use of jetty websocket instead of buildin websocket?

[mburger81]

Hello @knowledgecode again,

I tested your plugin and from the WebSocket side probably it works great. But there are some problems with cookies.
I think your plugin handles cookie forwarding right?

We use this cordova plugin https://github.com/silkimen/cordova-plugin-advanced-http to make native android http calls, for the same reason for we have to use your plugin.
The maintainer of the service we use have a CORS and an software origin check for https and wss calls.

The http plugin we use handle well cookies and anything is working, now the same cookie we have to use, are passed well over build in WebSocket but it seems it is not passed over your WebSocket implementation.

So how can we do something like that? Or should it worked out of the box? Can we set Cookie manual? And if not could this be a feature request :)

[mburger81]

We as many others use https://www.npmjs.com/package/cookiejar and https://github.com/salesforce/tough-cookie to handle cookies.
So the cookies are stored globally on default store from cookiejar.

I have a look on your code but I didn't understand what is your cookie integration.
I think to have a more global cookie support, because also in browser the cookies are passed between http and websocket requests, you should support cookiejar. Or at least you should add an interface to get and set cookies for urls. So users can handle it by there own.

What do you think?

[knowledgecode]

This plugin supports cookie just like built-in WebSockets. The reason cookies are not taken over it, you are not sending a http request with WebView in advance. Even if you use built-in WebSockets, cookies are not probably taken over it in case of using the libraries you mention. Consider using ajax or fetch instead of them.

[mburger81]

The reason for what we need to use this plugin and the native http plugin is, we need to remove origin header. There is no way to this with XHR over webview. So we have to use native calls to remove this header to get work.
So in your plugin you use native android.webkit.CookieManager which looks very good. And what you are saying is, if you do a browser http call over webview the heade is also stored there, and so your plugin "magically" is using the same websocket.

So probably it would be better the native http plugin should also use native CookieManager so anything should work out of the box. Right?

[knowledgecode]

Yes.

Cookies which Webview receives from a server are able to access via CookieManager. This plugin picks up the Same-Origin cookies from there, passes over them to WebSockets. If the native http plugin stores cookies to there, perhaps it can pick up them.