Skip to content

SimonVuong/ffreceiver

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

42 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Overview

The receiver is the rasberry pi that's plugged into the restaurant network via ethernet.

Each receiver has an id of length 10 generated by npm's nanoid (https://zelark.github.io/nano-id-cc/). Each receiver also has stored in its env variable, the RS256 private key which is generated via

ssh-keygen -t rsa -b 4096 -m PEM -f jwtRS256.key
# Don't add passphrase
openssl rsa -in jwtRS256.key -pubout -outform PEM -out jwtRS256.key.pub
cat jwtRS256.key
cat jwtRS256.key.pub

The public key is stored in elasticsearch along with the receiver id where id is the document identifier.

When the receiver is connected to the network, it will make a 'keep-alive' GET request to FFS (foodflick server) to path /register-receiver?id=<ID> and with header authentication: <id signed with private key>. This signature will also be stored in the environment variables since it won't change.

Upon receiving a GET request to /register-receiver?id=<ID>, FFS will verify the receiver by decrypting the authentication header with the public key stored in elasticsearch. If successful, then it will register the receiver. It's the restaurant manager's responsibility to add a specific receiver to their restuarant so that when FFS receiver an order for a restaurant, it can dispatch print requests to the restaurant specified receiver. if there is no receiver setup yet, then gotta error.

We use RS256 instead of HS256 (symmetrical key sign and verification) so that it is only possible to compromise one receiver at a time. If we used HS256, then we can either share the secret across all receivers, or give each receiver a seperate secret. A shared secret is bad because if it gets compromised, then all receivers are compromsied. Separate secrets are also bad because we need to store them in the db and if the db gets compromised then all receivers are compromised again. By using RS256 and storing only the public keys, we avoid both these problems.

Setup

to run as a service on rasberry pi boot...

make sure node is installed in the rasberry pi. follow first few steps here https://linuxize.com/post/how-to-install-node-js-on-raspberry-pi/.

make sure to allow ssh in case we need to debug on premise - preferences -> raspberry pi config -> interfaces -> enable ssh

make sure to allow make the pi wait for network on bootup - preferences -> raspberry pi config -> system -> check off wait for network

set up a static ip to match the subnet of the printers. create the following file, substituting address and gateway as necessary.

// /etc/network/interfaces.d/eth0
auth0 eth0
iface eth0 inet static
    address 10.0.0.10
    gateway 192.168.1.1
    netmask 255.255.255.0

clone the repo at the home location.

make sure to run npm install -g cross-env. make sure to update the config file to hold the correct receiverId

cd into repo and run npm run build. this will do npm install and package the files.

setup system d to run rasberry pi server by first creating the .service file

sudo cp tools/ffreceiver.service /lib/systemd/system

then... sudo systemctl daemon-reload so that systemd picks up the new file. sudo systemctl start ffreceiver to run it sudo systemctl enable ffreceiver to enable starting app on boot

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published