NT Web server sending command to remote Browser

[rjolda]

Hi All,
Again, I am not sure what to ask but here is the scenario.  I am looking at running a Kiosk with Raspberry PI.  I will have a browser in the kiosk which will connect to the NT server.  It will most likely be Chromium or Firefox for Raspberry Pi.  The kiosk is going to have a number of storage boxes.  At some point when the customer validates information on the NT server, the server will need to send a command to the kiosk ( it will know which kiosk to send the command to - and the kiosk browser will be connected to the NT Server). The command will be something like "unlock drawer #3".  At that point, the browser in the kiosk will send a notice to the onboard serial lock controller to unlock #3.   I just don't know enough about this browser stuff to get a handle on sending information to the remote (non NT browser client and having the non NT client browser act on it.  Seems like something for javascript in the client browser?  I am starting this project with Windows Computer in kiosk so will exchange values with a a NT client running on a web socket and channel.  SO, If I go to Raspberry Pi, how can my NT server send a command to the Browser running on the kiosk?  I am not sure if I can use javascript to program the Raspberry Pi browser to watch a socket or if I need to do an API query from the kiosk browser to NT server on a regular basis?
Any thoughts and insight would be helpful.
TIA,
Ron

[rjolda]

Hi All,
After lots of reading, I think that the solution is to Have a NT Server assign a port to each kiosk and it will send and listen on the assigned port for that kiosk.  On the kiosk side, I can write python code to talk to and listen on a specific port.  This way, the NT server and each kiosk can send messages back and forth ( not a frequent occurrance but necessary for operation) to get the job done.  I have to do more reading but his seems to be a solution.
Will let you all know when I try to implement it.
Ron

[Bruce]

That's not the real question.
The real question is "how you [safely] trigger the serial device?"

Traditionally browsers are isolated from hardware. So code running in the browser (JavaScript) cannot talk to a serial port, and so trigger your serial device. In this situation you need to run a small program on the client device (the Raspberry Pi) which reads and writes the serial port. Typically this program is also a _web server_ - because then the Browser can create a connection to it, send it a command, and so on.

Thus the browser talks to your main home server, and when it gets the ok to open a locker it triggers a request to the local server which then triggers the serial port.

Now, I say, traditionally, because in recent times there's a serial interface experiment happening in the browser. This means that the browser can interact directly with the serial port using JavaScript. Of course one would need to be very careful taking this approach. Since the browser is the "least secure" part of they system, if you use this API you make it _very_ tempting to attack the browser/Javascript with a view to it simply opening all the lockers.

So I think in a situation like yours, I would lean towards a more sophisticated system - one which relies on an encrypted one-time code being passed to the local server from the home NT server. In this way the home server issues a code which opens the locker. I'd code it something liek this;

a) home server decides a locker must be opened.
b) sends a "get random string" (aka a nonce) command to the browser, which in turn requests it from the local (python or whatever) server.
c) the local python server stores that string for a little bit.
d) the browser passes the string back to the home server, and the home server encrypts it using a private key.
e) the string is then passed back to the browser, and on to the local server. the local server decrypts it using a public key. And compares it to the nonce. If that passes then the instruction is executed. The python program then discards the stored nonce.

This prevents replay attacks (recording the command to open locker 2, then playing it back in the future.) By getting a one-time random nonce from the python program, and then including that in the command, the python program won't replay the command. So for example the command passed to the python server (encrypted) might be
{ "nonce" = "1234",
"cmd" : "open locker",
"locker" : 2}