As part of an ongoing side project involving my newly acquired Arduino, I’ve been thinking about datalogging, and specifically network based data logging – the goal being to have all the sensor data available for analysis, graphing, etc. I’ve decided to do this on my own server to get familiar with RRD, and PHP again rather then using a Web-based service like Xively.
Also given that Google values a thermostat company, Nest, at $3.2bn the temperature and other sensor data is clearly valuable in someone’s mind 🙂
As I sketched up a very simple GET submission of the data to a PHP page, it occurred to me that I didn’t want just anybody to be able to submit sensor data. So the question is ‘How can I allow a very simple datalogger to send in data, but block all others?’. For me one possible approach is HTTP Header Enrichment.
HTTP Header Enrichment is most commonly used by mobile operators to add interesting custom fields to HTTP Header requests, usually at the GGSN or just after in the Services Gateway. The typical application is to add the MSISDN or IMSI to HTTP requests going to internal self-service portals so that sign-in is not required from a mobile device.
Typical format used for this is X-something. This is not a formal requirement, as RFC2616 basically allows most things to be used in the headers, but was borrowed from RFC2047 Section 5 (since deprecated). This is a convention, not a requirement but it is one that I will use here.
Basically the approach is to have the server side code check for the custom header, and its value and if it matches what the client sends, then log the data. If not, then return HTTP 404 – Page Not Found.
<?php
$auth_key="my_shared_secret";
if($auth_key == $_SERVER['HTTP_X_AUTH_KEY']){
// Code to handle sensor data
}
else {
error_log("Auth Key Incorrect. Received value was $_SERVER['HTTP_X_AUTH_KEY']\n");
header('HTTP/1.0 404 Not Found');
exit;
}
>
$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here. HTTP_ is also added automatically as a prefix, and the hyphens (-) are replaced with underscores (_).
So on the client (arduino side) the code segment looks like:
client.print("GET /path/file.php?t="); client.print(t1); client.print("&v="); client.print(v1); client.println(" HTTP/1.1"); client.println("User-agent: Arduino Uno"); client.println("Host: flat-planet.net"); client.println("X-AUTH-KEY: my_shared_secret"); client.println("Accept: text/html"); client.println();
so we are sending X-AUTH-KEY and that is available to the server as HTTP_X_AUTH_KEY. As long as they match, all will work fine, and remember that X-AUTH-KEY can be anything, just ensure that it is meaningful for you.
