mozilla-sensorweb/sensorweb-server

SensorWeb server

Usage

Before running the server, you will need to install all its dependencies via

npm install

The server requires some initial configuration before being able to run. You can create your configuration file in config/{NODE_ENV}.json. Take config/sample.json as a starting point for your config file.

The server uses PostgreSQL as the database system, so make sure that you have it installed and running on your machine. If you are on a Mac, you can try running scripts/bootstrap-mac.sh to install and launch PostgreSQL with the default configuration.

Once all dependencies are installed and the config file is in place you can start the server by running:

npm start

The server should start running at http://localhost:8080

Running the tests

npm run test-watch

sensorweb-server's Issues

When returning a token after a successful authentication, we should have a status code of 200 instead of 201.

Ignore clients auth redirection URLs if the request contains an empty array

Preconditions to launch the ST test suite are not met

Here are the preconditions for the SenorThing API (STA) 1.0 Test Suite: http://cite.opengeospatial.org/te2/about/sta10/1.0/site/

According to the previous preconditions, there should be at least one entity per resource. It should be necessary to have data in the DB to test it.

Define and document token/client scopes

Move permissions out of config

#71 (comment)

Investigate changing the type used for `key` and `secret` in pg_store

If we are confident that these are fixed length strings, we could switch to varchar(N) instead of the current text.

Use common's functions where possible

In #47 there is a new common.js file whose goal is to build a toolkit for the most current operations. The goal is to use it for all needed set-up in the tests.

Be careful: do not use it for the actual tested behavior. For example, do not use common's loginAsAdmin if you're actually testing the admin login. Use it only when it's not the test's subject and it's merely a setup step to the test.

Get rid of basic authentication

Instead of using basic authentication for the admin user, it would be safer to use the OAuth based flow being implemented in #24 and have a list of allowed admin users.

Create Cloud support tooling

This is the tools need to support SensorWeb server environment.

Provide a gettime endpoint

The sensors need a time synchronization source, and we have been advised to not use a ntp server, but rather to rely on a simple https service.

The ideal return value for us would be the number of seconds since epoch.

Analytics

Add analytics, for example, requests per second, to support the beta release of the API.

Multi-tenant middleware

Multi-user middleware

Deploy sensorweb server pieces to a dev environment

Use latest version of Mozilla's SensorThings API

Use supertest-as-promised

So we can work with promises instead of using end + done callback in tests.

Client authentication

Document how can different sensorthings implementations be used in sensorweb-server

... and make sample.json config use Mozilla's sensorthings implementation.

Change the way the logging is made quiet in server.js

Currently we shut down the logging if we're in the test environment (see

sensorweb-server/src/server.js

Line 32 in 1da3319

if (config.get('env') !== 'test') {

). This is both fragile and not effective -- for example it's still used in circleci.

Instead we should use an env variable to control this. One possibility is to shush it when using the env vairable QUIET.

Change the way API errors are generated

#43 (comment)

Add a way to disable authentication

Form files would be needed to launch the ST Test Suite

Here are some examples of those files for other Test Suites:
https://github.com/geoserver/geoserver-cite-tools/tree/master/forms

There is nothing for sta10. We would need to create those files to be able to launch the test suite in headless mode.

Use OAuth instead of basic auth for admin login

Calculate new AWS cost estimates

Calculate new AWS cost estimates with these resources:

• 3x m3.medium ec2 servers to run SensorWebAPI, SensorThings API and Notifications Manager
  • this is a cluster so each server will run SensorWeb, SensorThings and a Notifications Manager
• 1x t2.medium for Sensors Heartbeat Monitor
• 1x t2.medium for admin console
• 1x db.r3.large (multi-az) for the database server
• 2x AWS ElasticLoadBalancers (for SensorThings and SensorWebAPI endpoints)

Add the __heartbeat__, __lbheartbeat__, and __version__ endpoints from dockerflow

Create Slate documentation

https://github.com/lord/slate

We have a great example at http://www.sensorup.com/docs/

Set Client.name as owner of SensorThing Things entities

Once mozilla-sensorweb/sensorthings#228 is done, we need to implement this as described in mozilla-sensorweb/sensorthings#228 (comment)

Define final AWS resources for production environment

Embed user auth query params inside auth token payload.

Instead of signing only the { id: <key>, scope: 'client' } parameters, we need to add the redirection urls to the JWT payload, so these parameters as signed as well.

Add support for CreateObservations endpoint

CreateObservations needs to be added to the list of resourceEndpoints

Require a 'redirect_url' parameter for client registrations

The authentication flow that we are designing for users and sensors requires each client to provide us with a redirection url during the clients registration process. In this redirection url clients will be receiving SW auth tokens.

User authentication (initially with Facebook only)

Apply Dockerflow

Expose /permissions to allow admin users to obtain a list of possible permissions

TLS support

Run OGC compliance tests on Travis CI

Session tokens must always contain clientId, userId (if any) and the list of allowed permissions

Right now we are generating two kind of session tokens:

• For the admin user, with a payload like:

{
  "id": "admin",
  "scope": "admin"
}

• For regular users, with a payload like:

{
  "id": {
    "opaqueId": "facebook_id",
    "provider": "facebook",
    "clientKey": "02e9c7"
  },
  "scope": "user"
}

Session tokens must always contain a client key, a list of allowed permissions, and may have or may not have a user associated. So we should end up with:

• Anonymous session tokens:

{ 
  "clientId": "1234567890987654321",
  "scopes": ["sensorthings"]
}

• User session tokens:

{
  "clientId": "1234567890987654321",
  "userId": {
    "opaqueId": "facebook_id",
    "idp": "facebook"
  },
  "scopes": ["sensorthings"]
}

The list of permissions is tbd in #53

Allow setting the list of allowed permissions for a client

Define and implement logging strategy

Having log files is always very useful, let's implement some logging strategy for this service.

Sensors authentication

Tests simplification: use promises, generators and template strings

In many tests (eg test_auth_api.js) we have:

• string concatenation
• callback-based tests (with mocha's done)
• asynchronous code using promises or (worse !) callbacks

We can make them more readable using (respectively) template strings, promises and generators (using co-mocha).

Get some of the PostgreSQL configuration from the config file.

pg_store currently just uses the default database connection for the "sensorweb" db.

User favorites API

We need an API to fulfill the following user stories:

• As a user, I want to track multiple locations where I want to keep track of air quality so that I am on top of things without repeating the same search each time.
• As a user I should be able to save a sensor to my favorites so that it will appear on a favorite view with labels so that I can see them easily
• As a user I should be able to rename a favorite sensor
• As a user I should be able to stop tracking a sensor as a favorite location.