43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
# Serving Data
|
|
|
|
This project includes to data servers: the solar server and electricity server. Both host the data collected by their respective logger counterparts.
|
|
|
|
## API Description
|
|
|
|
[The solar api description](./SOLAR_API.md)
|
|
[The electricity api description](./ELECTRICITY_API.md)
|
|
|
|
## Reverse Proxy
|
|
|
|
It is recommended to use a reverse proxy setup to make all servers and content reachable through standard HTTP(S) ports. When using nginx something like this suffices, using the solar server as example:
|
|
```
|
|
server {
|
|
server_name solar.valkendaal.duckdns.org;
|
|
location / {
|
|
if ($request_method = 'GET') {
|
|
add_header 'Access-Control-Allow-Origin' '*';
|
|
add_header 'Access-Control-Allow-Methods' 'GET';
|
|
}
|
|
proxy_pass http://localhost:3001;
|
|
}
|
|
}
|
|
```
|
|
|
|
The additional if statement within the location scope allows fetching of solar resources by any other domain. This is used to display data exposed by the solar server on the website (`public/`).
|
|
|
|
## Restricting Access
|
|
|
|
The electricity server exposes sensitive data, hence it shouldn't be accessible to anyone except users of the household. The easy solution here is to verify the requestee's IP address, since anyone making the request from the household itself should share the same external IP address, including the server. Therefore the electricity server checks the requestee's IP address against its own external one (by resolving the given domain parameter argument to an IP address).
|
|
|
|
For this a little hackery was necessary in the reverse proxy, since it normally makes the request to the electricity server on its own behalf. This would result in all requests originating from 127.0.0.1 (localhost). To solve this the following line was added before the `proxy_pass` directive:
|
|
```
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
```
|
|
|
|
The value of the X-Real-IP HTTP header is then used by the electricity server to validate against the domain resolved IP address. If they match it means the request came from the same network as the server.
|
|
|
|
This obviously is not watertight, but it serves the purpose well enough and avoids having to lay down more complicated authorization infrastructure.
|
|
|
|
## Launch Parameters
|
|
|
|
Both servers use TCLAP for their launch parameters. Simply run either executable without any parameters or use the `--help` switch to get all available commands. |