Author Topic: New JavaScript Bindings for Test  (Read 17391 times)

iia

  • Newbie
  • *
  • Posts: 9
    • View Profile
New JavaScript Bindings for Test
« on: February 18, 2014, 16:50:18 »
Hei Tinkerers,

We have finished working on the new Javascript bindings which will support both browser and Node.JS. Currently for testing only the Node.JS version is available.

The bindings are already in NPM registry.

First of all, you need to have a working Node.JS installation and NPM installed on your system (better if they are updated to the latest version).

Then you can install the bindings using the following command,
Code: [Select]
sudo npm -g install tinkerforge
You must make sure that the environment variable `NODE_PATH` is in your env list. This is usually pointing to `/usr/local/lib/node_modules/`.

After that you should be able to try out all the examples found in the attached archive with the following command,
Code: [Select]
node <exmaple_to_execute.js>
Don't forget to change the UID and network parameters depending on the setup you are testing on.

Have fun trying out the new bindings and it would be very much appreciated if you post your findings and feedback on this post.


Cheers,
Ishraq
« Last Edit: February 18, 2014, 16:52:01 by iia »

borg

  • Administrator
  • Hero Member
  • *****
  • Posts: 3.044
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #1 on: February 20, 2014, 14:35:37 »
I just added a miniature version of a websocket server to brickd: https://github.com/Tinkerforge/brickd/commit/45b8da4a27af5c61054ea8093e2a1149784e7b23

It needs some more testing before we can publish it as a beta, but i already have a question about some details:

What do you think would be the right port for the websocket server in brickd? I am currently using port 80 (as defined in the standard). But this will obviously interfere with normal webservers if they happen to run on the same machine.

Do you think we should use a default websocket port that is different from 80? Independent of the default port you can change the port in the brickd config of course.
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

Equinox

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #2 on: February 20, 2014, 15:15:58 »
Hi,

please don't use port 80 as default. I suggest to use something uncommon that other servers aren't likely to use, i.e. please also don't use 8080, 8888, etc. I suggest e.g. 16880.

Loetkolben

  • Hero Member
  • *****
  • Posts: 1.167
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #3 on: February 20, 2014, 19:51:16 »

Hello,

TF Port is 4223, alternative could be 8023 or 4280. Not common, but self-evident.

Der Loetkoben

Equinox

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #4 on: February 22, 2014, 15:33:41 »
Hello,

I did some simple tests with the new Bindings. Everything worked fine except for the example in "ExampleSwitchSocket" for the RemoteSwitch-Bricklet.

Error message:
Code: [Select]
/home/pi/node_progs/tinkerforge/RemoteSwitch/ExampleSwitchSocket.js:24
        rs.switchSocketA(17, 1, BrickletRemoteSwitch.SWITCH_TO_ON);
                                ^
ReferenceError: BrickletRemoteSwitch is not defined
    at Object.0 (/home/pi/node_progs/tinkerforge/RemoteSwitch/ExampleSwitchSocket.js:24:33)
    at IPConnection.handleConnect (/home/pi/node_modules/tinkerforge/lib/IPConnection.js:280:70)
    at Socket.EventEmitter.emit (events.js:117:20)
    at Object.afterConnect [as oncomplete] (net.js:883:10)


Replacing "BrickletRemoteSwitch.SWITCH_TO_ON" with "1" works fine.
Setup:
Tinkerforge stack is connected via WiFi Extension to a Raspberry Pi running Node.js in version v0.10.23.

iia

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #5 on: February 24, 2014, 10:45:33 »
Dear Equinox,

Good finding. The problem is it should be,

Code: [Select]
Tinkerforge.BrickletRemoteSwitch.SWITCH_TO_ON

instead of,

Code: [Select]
BrickletRemoteSwitch.SWITCH_TO_ON
Will be fixed in the examples.

Equinox

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #6 on: February 24, 2014, 17:38:51 »
Hi,

works great now!

photron

  • Administrator
  • Hero Member
  • *****
  • Posts: 2.351
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #7 on: February 26, 2014, 20:58:41 »
Here's Brick Daemon 2.1.0 RC1 that accepts WebSocket connections on port 4280:

Windows, Linux (amd64, i386, armhf), Mac OS X

And here's also an updated version of the JavaScript bindings that includes the browser version of the bindings and examples for them.

tinkerforge_javascript_bindings_2_0_0_rc1.zip

Just put an example HTML file and the Tinkerforge.js file from the browser subdirectory in the ZIP in the same directory and open the HTML file in your browser. This was tested and works in the latest versions of Chrome/Chromium, Firefox and Internet Explorer. Other browsers that support the current WebSocket version should work as well.

Loetkolben

  • Hero Member
  • *****
  • Posts: 1.167
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #8 on: February 27, 2014, 01:56:14 »
RESPEKT!  :D  It works!


BTW:

~# dpkg -i brickd-2.1.0-rc1_i386.deb
Vorbereitung zum Ersetzen von brickd 2.0.10 (durch brickd-2.1.0-rc1_i386.deb) ...
 brickd hängt ab von pm-utils; aber:    <--- ??
  Paket pm-utils ist nicht installiert.

~# apt-get -f install
Die folgenden zusätzlichen Pakete werden installiert:
  libx86-1 pm-utils powermgmt-base vbetool
Vorgeschlagene Pakete:
  cpufrequtils wireless-tools ethtool radeontool


Quote
Package: pm-utils (1.4.1-9)
utilities and scripts for power management
This package provides simple shell command line tools to suspend and hibernate your computer.



Der Loetkolben
« Last Edit: February 27, 2014, 01:59:30 by Loetkolben »

photron

  • Administrator
  • Hero Member
  • *****
  • Posts: 2.351
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #9 on: February 27, 2014, 11:13:37 »
Loetkolben, the new requirement for pm-utils is intended. It's part of the fix for the problem that brickd fails to talk to USB devices after a suspend on Linux and Mac OS X. There is a thread about this in the German board:

http://www.tinkerunity.org/forum/index.php/topic,2169.0.html

Robin

  • Guest
Re: New JavaScript Bindings for Test
« Reply #10 on: February 27, 2014, 12:20:14 »
I expect  the new binding might be a security risk. I think that it is possible to use this binding on any website? In this case external web pages would be able to connect to a stack. If they switch a Bricklet like the analog out, they could destroy the device which is used with it. I recommend to add a pass code protection to make sure external web pages can't connect.

borg

  • Administrator
  • Hero Member
  • *****
  • Posts: 3.044
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #11 on: February 27, 2014, 13:18:32 »
The risk is the same as before, but i can see your point. It is easier to get me to open a malicious website that uses port 4280 then to plant a malicious program on my pc that uses port 4223.

I see two possible ways to prevent an attack from a random malicious website:

1. We use the origin field from the websocket handshake. In this case the user would have to give the brickd or Ethernet Extension a list of websites that are allowed to connect. The problem here is that we can't store a big list of websites on the Ethernet Extension, perhaps two or three?

Another problem is that URLs are allowed to use any UTF8 character nowadays, we may have problems handling some URLs on the Brick because of that.

2. We (mis-)use the Sec-WebSocket-Protocol field of the websocket handshake and add a passphrase to our protocol that has to be configured for the Ethernet Extension or brickd. This would stop the attacks from a random malicious website but it couldn't do anything against "man-in-the-middle" attacks for obvious reasons.

But for security relevant projects where you fear that someone is trying to actively attack your Bricks/Bricklets you should only allow secure connections from a VPN or similar in any case!

Edit: We could also add the passphrase to the Request-Line field of the websocket handshake. That would probably make more sense, we wouldn't have to misuse any of the handshake fields.
« Last Edit: February 27, 2014, 13:36:52 by borg »
Wir sind die Borg, Widerstand ist Spannung durch Stromstärke!

Loetkolben

  • Hero Member
  • *****
  • Posts: 1.167
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #12 on: February 27, 2014, 15:03:35 »
Hallo photron,

thanks for the "pm-utils" note.  :)


Hello Robin, borg.

I´m not shure if you talk about the same thing? The BROWSER connects to the Stack. ONLY local PC (Same Network) can access the Stack. NOT the Webserver is connecting to the Stack. This is the same situation as with the Brickviewer.


Or am I wrong?

Edit: I think I am wrong. If you load a webpage from external server, it can search/connect inside your local network for hosts with open port 4280.

Neverless. As discussed many times ago a PIN protection in the protocol, also for port 4223, would be fine. This gives protection if the Stack is reachable from outside via Router-Portforwarding.


Der Loetkolben
« Last Edit: February 27, 2014, 16:15:16 by Loetkolben »

photron

  • Administrator
  • Hero Member
  • *****
  • Posts: 2.351
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #13 on: February 27, 2014, 15:20:38 »
This is the same situation as with the Brickviewer.

No. An external party/attacker cannot access your stack, assuming you didn't expose port 4223 to the Internet.

But with WebSocket support in brickd any website you open in your browser can access your stack via the brickd WebSocket, even if the WebSocket is only reachable from your PC. So any website out there that you open in your browser can access your stack, even if you didn't expose port 4280 to the Internet.

The problem here is that you're basically running untrusted code from external sources in your browser. That's why there is so much sand-boxing in modern browsers. That's also the reason why WebSockets in the browser cannot connect to normal sockets. Otherwise any website could access all services on your local network via your browser.

So, a malicious webserver cannot attack your stack directly, but it can deliver you a website that can do this.

Equinox

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
Re: New JavaScript Bindings for Test
« Reply #14 on: February 27, 2014, 17:29:03 »
Hi,

Quote
So any website out there that you open in your browser can access your stack, even if you didn't expose port 4280 to the Internet.

How does this work? If I block port 4280 for accesses from the Internet, I think (and hope) that no browser will be able to access the stack. Of course, if you want to access your stack from the Internet, that doesn't work either.