Packaging with Electron ...

233 views
Skip to first unread message

Gareth Bult

unread,
Sep 28, 2016, 12:11:06 PM9/28/16
to Autobahn
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.




Gareth Bult

unread,
Sep 28, 2016, 12:12:33 PM9/28/16
to Autobahn
Sorry, electron is v1.4.1 and Autobahn is v10.1, Chrome is 52.0.2743.116, OS is Ubuntu 16.04.

Tobias Oberstein

unread,
Sep 29, 2016, 2:48:45 AM9/29/16
to autob...@googlegroups.com
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;

Gareth Bult

unread,
Sep 29, 2016, 5:26:47 AM9/29/16
to Autobahn
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.

Tobias Oberstein

unread,
Sep 29, 2016, 6:10:43 AM9/29/16
to autob...@googlegroups.com
> - 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.
>

Gareth Bult

unread,
Sep 29, 2016, 6:26:15 AM9/29/16
to Autobahn
.. if it's just a Node issue, I'm much happier .. :)

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?

Tobias Oberstein

unread,
Sep 29, 2016, 7:20:50 AM9/29/16
to autob...@googlegroups.com
No, because AutobahnJS works on NodeJS.

The issue seems related to Electron specifically.

Gareth Bult

unread,
Sep 29, 2016, 11:58:10 AM9/29/16
to Autobahn
Ok, so .. I made it work .. :)

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;

<script>
   
var isOnNodeJs = false;
   
if(typeof process != "undefined") {
      isOnNodeJs
= true;
   
}
</script>
<script>
   
if(isOnNodeJs) {
       
var autobahn=require("/usr/local/lib/node_modules/autobahn/lib/autobahn.js");
   
} else {
        $
.getScript("js/autobahn_min.js" );
   
}
</script>

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 <script src> it sees the Electron version that doesn't ??

tia
Gareth.

Alexander Gödde

unread,
Sep 30, 2016, 4:33:32 AM9/30/16
to Autobahn
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 

Gareth Bult

unread,
Sep 30, 2016, 5:01:52 AM9/30/16
to Autobahn
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 <script> 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 <script src> doesn't work and whether it's possible to make it work .. (?)

Regards,
Gareth.

Tobias Oberstein

unread,
Sep 30, 2016, 7:11:47 AM9/30/16
to autobahnws

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

Sent from Mobile (Google Nexus 5)


--
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.

Gareth Bult

unread,
Sep 30, 2016, 7:24:52 AM9/30/16
to Autobahn
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.
Reply all
Reply to author
Forward
0 new messages