Drupal and the Internet of things
Drupalcamp Oslo 2015
Eirik Morland
Ny Media
Eirik?
- Developer
- Beer nerd (although not beer snob)
- Not so good at soldering
Internet of things?
The Internet of Things (IoT) is the network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data.
What we will cover
- Communication patterns / flow
- Authentication and security
- Animated GIFs, blinking LEDs, cats and dogs.
What we will not cover
Other ways to do Drupal and IoT
- Install Drupal on a Raspberry Pi
- Attach some wires
- Enable Php module
- create a node with PHP filter that reads $_GET
- Run exec("sudo ...");
- ...?
- Profit?
To demo or not to demo?
Pros
- What could possibly go wrong?
Cons
1st demo
Offline status checker (esp8266 and LED)
Video demo
What happens here?
- Not a very smart "thing".
- One-way communication (Drupal site does not know what requests it)
- Only checks the status code (200 or not).
- Turns on LED based on status code.
- Not very Drupal specific.
- Uses no authentication (no secret data is used, status code is "public")
2nd demo
Toggle maintenance mode with a TV remote.
Video demo
What happens here?
- Microcontroller receives IR signal.
- Makes a request to a Drupal site, that has a path exposed to toggle maintenance mode.
- Request uses session cookie to authenticate.
- Kind of "headless" interaction with the Drupal site (we will expand on this later).
Pros and cons about session authentication.
Pros
- Easy to set up.
- Uses the same permission system as the regular front-end.
Cons
- Not persistent (time based).
- Follows the browser session (if you log out of the browser, the "thing" will be logged out).
- If session gets compromised, all permissons with that user gets available to attacker. You don't compromise an endpoint, but a user.
Reminder #1
ALWAYS USE HTTPS
3rd demo
Headless and decoupled "thing" counting nodes.
Video demo
What happens here?
- Drupal saves a node, publishes a key in Redis.
- Counter is communicating with a node.js server that listens for a key in Redis.
- Upon change, query the "rest-version" of the front page and count number of nodes.
- Rest query is as anonymous user, so it reflects the state of the frontpage (published/promoted).
Both decoupled and headless
4th demo
Raspberry Pi monitoring temperatures and posting them as nodes.
Video demo
What happens here?
- Raspberry Pi senses temperature.
- Every 3 minutes (and on start) it sends the temperature to an endpoint using an API key.
- API keys are per user. If they are valid, a node is posted.
Pros and cons about API keys.
Pros
- If key is compromised, the key only gives access to one specific thing (not the whole permission system and thus the user).
- Keys can be regenerated system-wide and per user.
- Keys can be persistent and with no relation to user sessions.
Cons
- This particular use-case is a custom module (could theoretically be an authentication strategy for core REST module).
- Still can be sniffed over plain HTTP.
5th demo
Arduino node analysis, post TV remote off signal when a picture of a dog appears.
Video demo
What happens here?
- Arduino superspeed processor does a GIF frame by frame analysis and recognises a dog in the GIF. Sends a NUKE LAZER command that reaches all the way to London (where the server is) and melts down the server farm of Linode.
- ^^ (Just kidding).
- Same decoupled node.js backend receives the node title as a key, find the word "dog" in it.
- When "dog" is found, an IR signal is sent out (corresponding to a certain TV on/off toggle button)
- Ardiuno does not care what receives the signal, so it is picked up and the toggle maintenance mode is sent.
- The offline LED monitor picks up the offline mode of the site.
Some thoughts on dependencies on devices, services and Drupal in general
- The Drupal site does not care who listens to a key, it just publishes something to redis.
- The node.js backend does not care where the redis publish came from. It just relays information.
- The Arduino does not care if the data it receives comes from Drupal or the node.js backend. Nor does it care if the IR signal is sent to a TV.
- The Tessel does not care about if the signal comes from a remote. Nor does it care if the toggle request is for a Drupal site.
- The Drupal site does not care about the origin of the toggle request, it only cares about authentication.
- The status monitoring does not care about anything at all.
6th demo
Voice recognition, post a node based on this, with a picture, via the REST module.
Video demo
- A "thing" is recording and upon silence is doing voice analysis of last recording.
- If the word "cat" or "dog" is found, a node posting starts:
- POST a new file entity via REST module (REST endpoint for file)
- POST a new node entity via REST module, and attach the newly created file (REST endpoint for node).
- The node has a title based on keyword (for example "a picture of a dog".
- If the word "dog" is in the title, the IR signal for TV on/off is sent.
- If the IR signal for TV ond/off is sent, request is sent for maintenance mode toggle on/off.
- If maintenance mode is enabled, status checker goes red.
Autentication via REST module
- Uses the Basic auth module in core.
- Does not "interfere" with regular user sessions.
- Will (in theory) only provide access to REST resources if compromised.
- (although since this is basic auth you are basically giving away your password as well)
- Super important (still) with https.
Take aways?
- Always, always use https.
- Different strategies for autentication and security
- Different patterns for communicating.
- Drupal 8 is awesome.
- Use https.
- Eirik is not very good at soldering.
- This upcoming gif
Drupal and the Internet of things
Drupalcamp Oslo 2015
Eirik Morland
Ny Media
@orkj