Packaging with Electron ...

#1

Hi, I’m just trying to get my application working with Electron … works fine via the browser, but when I try from Electron, it throws Autobahn errors.

Here’s my **main.js **file;

`const electron = require(‘electron’);
const { app, BrowserWindow } = electron;

let mainWindow;

app.on(‘ready’, () => {
mainWindow = new BrowserWindow({
width: 1920,
height:1080,
“web-preferences” : { “web-security” : false }
});
mainWindow.setTitle(‘iFlexRTS Studio’);
mainWindow.loadURL(‘http://localhost:8081’);
mainWindow.on(‘closed’, () => { mainWindow = null; });
});
`

Which I subsequently run with;

electron main.js

``

Although the HTTP stuff fires up Ok, as soon as I try to make a WAMP connection I get;

iflex.js:61 > Initializing …ws://localhost:8081/ws
iflex.js:36 # iflex.js:62 > Autobahn version …0.10.1
iflex.js:36 # iflex.js:67 > Connecting with (guest) credentials
autobahn_min.js:1142 Refused to set unsafe header “Sec-WebSocket-Version”(anonymous function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header “Sec-WebSocket-Key”(anonymous function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header “Sec-WebSocket-Protocol”(anonymous function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header “Sec-WebSocket-Extensions”(anonymous function) @ autobahn_min.js:1142
http://localhost:8081/ws Failed to load resource: the server responded with a status of 426 (HTTP Upgrade header missing)

``

Anyone any idea on what's causing this / how to get around it .. ??

tia

Gareth.

0 Likes

#2

Sorry, electron is v1.4.1 and Autobahn is v10.1, Chrome is 52.0.2743.116, OS is Ubuntu 16.04.

0 Likes

#3

Hi Gareth,

I have zero clue about Electron .. so I am just guessing here:

"Refused to set unsafe header "Sec-WebSocket-Key""

Not sure if this is Autobahn specific.

I would try packaging a trivial Javascript with Electron that opens a raw WebSocket connection - so no Autobahn at all.

Here is a client

https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/websocket/echo/client.html

that will work with

https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/websocket/echo/server.py

or any other WebSocket echo server endpoint.

Cheers,
/Tobias

···

Am 28.09.2016 um 18:11 schrieb Gareth Bult:

Hi, I'm just trying to get my application working with Electron .. works
fine via the browser, but when I try from Electron, it throws Autobahn
errors.

Here's my *main.js *file;
const electron = require('electron');
const { app, BrowserWindow } = electron;

let mainWindow;

app.on('ready', () => {
    mainWindow = new BrowserWindow({
        width: 1920,
        height:1080,
        "web-preferences" : { "web-security" : false }
    });
    mainWindow.setTitle('iFlexRTS Studio');
    mainWindow.loadURL('http://localhost:8081');
    mainWindow.on('closed', () => { mainWindow = null; });
});

Which I subsequently run with;

electron main.js

Although the HTTP stuff fires up Ok, as soon as I try to make a WAMP
connection I get;

iflex.js:61 > Initializing ......ws://localhost:8081/ws
iflex.js:36 # iflex.js:62 > Autobahn version ..0.10.1
iflex.js:36 # iflex.js:67 > Connecting with (guest) credentials
autobahn_min.js:1142 Refused to set unsafe header "Sec-WebSocket-Version"(anonymous
function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header "Sec-WebSocket-Key"(anonymous
function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header "Sec-WebSocket-Protocol"(anonymous
function) @ autobahn_min.js:1142
autobahn_min.js:1142 Refused to set unsafe header "Sec-WebSocket-Extensions"
(anonymous function) @ autobahn_min.js:1142
http://localhost:8081/ws Failed to load resource: the server responded with
a status of 426 (HTTP Upgrade header missing)

Anyone any idea on what's causing this / how to get around it .. ??

tia
Gareth.

0 Likes

#4

Ok, I think I may have found the problem, but if I’m right I don’t think it’s good …

First, I tried as you suggested, with main.js like this;

const electron = require(‘electron’);
const { app, BrowserWindow } = electron;

let mainWindow;

app.on(‘ready’, () => {
mainWindow = new BrowserWindow({ width: 1920, height:1080, });
mainWindow.setTitle(‘iFlexRTS Studio’);
mainWindow.loadURL(‘file:///home/gareth/iFlexStudio/master/client.html’);
mainWindow.on(‘closed’, () => { mainWindow = null; });
});

``

Running server.py separately with;

python3 server.py &
electron main.js

``

Resulting console output looks like this - so I’m guessing it’s working as intended;

Connected!
client.html:35 Text message sent.
client.html:16 Text message received: Hello, world!
client.html:46 Binary message sent.
client.html:23 Binary message received: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f

``

My theory

  • Autobahn is using setRequestHeader****to set 4 different headers which start with “sec”, I’m guessing to facilitate the socket ‘upgrade’.
  • Node.js was relatively ‘relaxed’ about setting headers, but newer versions are being tied to the W3 specification.
  • The current W3 specification says the programmer is not allowed to explicitly set headers beginning with “Sec-”
    (https://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-setrequestheader)

If I’m right (?) this would imply that Autobahn won’t work with newer versions of Node … (?)

What is really worrying me is that if I’m right (?) and if Google were to do the same with Chrome, everything Autobahn would just ‘stop working’ …

This seems to be the ‘fatal’ part of the error;

Failed to load resource: the server responded with a status of 426 (HTTP Upgrade header missing)

``

With the server reporting;

Failing Websocket opening handshake (‘HTTP Upgrade header missing’)

``

Is it possible to get the server to allow the process to work ‘without’ needing the additional “Sec-” options?

tia

Gareth.

0 Likes

#5

   - Autobahn is using setRequestHeader to set 4 different headers which
   start with "sec", I'm guessing to facilitate the socket 'upgrade'.

No, this isn't coming from AutobahnJS, but the underlying WebSocket implementation, which browsers have natively built in, and on NodeJS comes from the "ws" library

   - Node.js *was* relatively 'relaxed' about setting headers, but newer
   versions are being tied to the W3 specification.

No, this hasn't anything to do with W3C, but IETF RFC6455.

   - The current W3 specification says the programmer is not allowed to
   explicitly set headers beginning with "Sec-"
   (
   https://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-setrequestheader
   )

This doesn't apply. WebSocket != XMLHttpRequest

If I'm right (?) this would imply that Autobahn won't work with newer
versions of Node .. (?)

No, the WebSocket library in NodeJS we use ("ws") directly talks on top of TCP.

What is *really* worrying me is that if I'm right (?) and if Google were to
do the same with Chrome, everything Autobahn would just 'stop working' ...

No, no need to worry. It works, and will continue to do so.

This is specific to Electron or what ..

This seems to be the 'fatal' part of the error;

Failed to load resource: the server responded with a status of 426 (HTTP
Upgrade header missing)

With the server reporting;

Failing Websocket opening handshake ('HTTP Upgrade header missing')

Is it possible to get the server to allow the process to work 'without'
needing the additional "Sec-" options?

No, not possible. RFC6455 requires these headers.

Cheers,
/Tobias

···

tia
Gareth.

0 Likes

#6

… if it’s just a Node issue, I’m much happier … :slight_smile:

Sorry, I’m afraid I’ve not really been working down at this level so I’m a little lost … (and I too am new
to Node…)

Do I understand correctly that the issue seems to be that the NodeJS “ws” library is refusing “Sec-” header

options when it should be allowing them?

0 Likes

#7

No, because AutobahnJS works on NodeJS.

The issue seems related to Electron specifically.

···

Am 29.09.2016 um 12:26 schrieb Gareth Bult:

.. if it's just a Node issue, I'm much happier .. :slight_smile:

Sorry, I'm afraid I've not really been working down at this level so I'm a
little lost .. (and I too am new
to Node...)

Do I understand correctly that the issue seems to be that the NodeJS "ws"
library is refusing "Sec-" header
options when it should be allowing them?

0 Likes

#8

Ok, so … I made it work … :slight_smile:

All I need to do now is understand why is works … essentially if I load the “native” version of Autobahn installed via NPM, it works,
but if I just load the version I use “online”, it does not. Is this because there are two different versions of Autobahn, or is it because
each starts differently or in a different context?

It would be a lot “neater” if the web version just works in Electron, but this is what I’m doing for the moment (actually it’s a bit horrible, but …)

a. npm install autobahn -g (install autobahn as a global node module)

b. modify index.html like so;

``

``

Any ideas?

Could it be there are two implementations of “XMLHttpRequest” (Node and Electron) and when you “require” Autobahn sees the working

Node version, but when you it sees the Electron version that doesn’t ??

tia

Gareth.

0 Likes

#9

Hi Gareth,

when running under Node.js you need to load Autobahn|JS as a module. As a matter of fact, for anything that is supposed to be be able to run both in the browser and on Node.js, we have

try {

// for Node.js

var autobahn = require(‘autobahn’)

} catch (e) {

// for browsers (where AutobahnJS is available globally

}

at the beginning of the JS file.

Regards,

Alex

···

Am Donnerstag, 29. September 2016 17:58:10 UTC+2 schrieb Gareth Bult:

Ok, so … I made it work … :slight_smile:

All I need to do now is understand why is works … essentially if I load the “native” version of Autobahn installed via NPM, it works,
but if I just load the version I use “online”, it does not. Is this because there are two different versions of Autobahn, or is it because
each starts differently or in a different context?

It would be a lot “neater” if the web version just works in Electron, but this is what I’m doing for the moment (actually it’s a bit horrible, but …)

a. npm install autobahn -g (install autobahn as a global node module)

b. modify index.html like so;

``

``

Any ideas?

Could it be there are two implementations of “XMLHttpRequest” (Node and Electron) and when you “require” Autobahn sees the working

Node version, but when you it sees the Electron version that doesn’t ??

tia

Gareth.

0 Likes

#10

Hi Alex,

Sure, this is essentially the conclusion I’ve reached, although with Electron it seems to be a little more complicated.

Firstly the requirement to load a local module is messy and far less portable than loading via src, as it requires
each installation to install and maintain local modules for the application - so I’m trying to understand why this is necessary.
(it’s not necessary for other complex libraries such as jQuery, autobahn is the “only” module I seem to need to load this way)

Secondly, under Electron, if you define autobahn in main.js, the autobahn variable is not visible in the resultant application
referenced by “loadURL”, and my attempts to pass “autobahn” into “loadURL” from “main.js” have thus far been unsuccessful.
(in that I can pass the variable, but for some reason autobahn does not make a connection)

The only way I’ve been able to make it work so far is as documented above, by calling “require” from within the “loadURL” referenced
application, and the problem here is that at this point, it does not seem to honour require’s search path behaviour, hence the only way

I’ve been able to make it play ball is to reference an absolute URL, which again is a long way from portable.

I can spend more time trying to resolve the search path issue / going for a cleaner solution on the NodeJS module side, but I’m still
torn as to why the most elegant solution, i.e. autobahn via doesn’t work and whether it’s possible to make it work … (?)

Regards,

Gareth.

0 Likes

#11

Hi Gareth,

when running under node, the autobahnjs from npm should be used and imported using require. This is expected for node libraries and works perfectly.

Cheers,

Tobias

···

Am 30.09.2016 11:01 vorm. schrieb “Gareth Bult” garet...@gmail.com:

Hi Alex,

Sure, this is essentially the conclusion I’ve reached, although with Electron it seems to be a little more complicated.

Firstly the requirement to load a local module is messy and far less portable than loading via src, as it requires
each installation to install and maintain local modules for the application - so I’m trying to understand why this is necessary.
(it’s not necessary for other complex libraries such as jQuery, autobahn is the “only” module I seem to need to load this way)

Secondly, under Electron, if you define autobahn in main.js, the autobahn variable is not visible in the resultant application
referenced by “loadURL”, and my attempts to pass “autobahn” into “loadURL” from “main.js” have thus far been unsuccessful.
(in that I can pass the variable, but for some reason autobahn does not make a connection)

The only way I’ve been able to make it work so far is as documented above, by calling “require” from within the “loadURL” referenced
application, and the problem here is that at this point, it does not seem to honour require’s search path behaviour, hence the only way

I’ve been able to make it play ball is to reference an absolute URL, which again is a long way from portable.

I can spend more time trying to resolve the search path issue / going for a cleaner solution on the NodeJS module side, but I’m still
torn as to why the most elegant solution, i.e. autobahn via doesn’t work and whether it’s possible to make it work … (?)

Regards,

Gareth.

You received this message because you are subscribed to the Google Groups “Autobahn” group.

To unsubscribe from this group and stop receiving emails from it, send an email to autobahnws+unsubscribe@googlegroups.com.

To post to this group, send email to autob...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autobahnws/c9d2ec70-3a4b-4f94-9ec4-f3d9b3d7474d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#12

Hi,

I absolutely understand that it should and that it works perfectly, what I’m trying to understand is “why”.

I will ponder …

Regards,

Gareth.

0 Likes