have statusServer() return json data and wrap in a php front-end

[jbrzusto]

By providing a clean JSON-based API (as for dataServer), we gain:

• reduced load on the Rook app, transferring it to Apache
• customization of web interface doesn't have to touch R code Initially, a simple php wrapper will serve the status.

Overall design:

• R rook applications in statusServer() return JSON-formatted results
• php3 wrappers that present the web interface call this API, and otherwise do not access the filesystem or database

[jbrzusto]

see Denis' elaboration and comments in #265

[jbrzusto]

Basic Design of Status API

authentication

For status, we (i.e. the php wrapper) currently authenticate (username, password) against motus.org/api/user/authenticate, then generate a ticket: a signed username+group tokens which can be verified by any program having access to the single shared secret used in signing. This means all points requiring authentication by ticket can check tickets using only the static shared secret, rather than requiring access to a dynamic database of tokens or username/password pairs. The ticket does not leak password information, and group tokens cannot be spoofed.

However, the static shared secret must be updated from time to time for better security, which is a maintenance chore.

Summarizing the options

• apache mod-auth-tkt:

  • ticket can be passed between status, download and (when moved to new server) uplaod pages via the browser, so that there's only a single sign-on required. However,

  • tickets depend on a secret stored on the data server in the apache config file, and this should occasionally be changed, which is annoying.

• token stored in DB:

  • currently used by the dataServer; we only have R code to generate this, although it's a quick translation to php if we want to implement it for wrapper layers

  • need to sort out "cookification" so that it can be returned as a cookie where needed

  • doesn't depend on a server-side secret, so doesn't entail the occasional maintenance job of secret regeneration

  • does require access to the DB storing tokens, for lightweight lookups by token

  • data API is currently stand-alone, and not directly browser-accessible, so perhaps it's not necessary to blend these, although some wrappers would want easy access to both.

  • hybrid solution:

  • use both as above, but have dataServer accept the ticket instead of an auth token. Tickets are recognizable by having a '!', which authTokens lack. The ticket would have to be validated, which is a bit more expensive than a database token lookup, but would still be only a fraction of the cost of the entire API call in most cases. We can modify the ticket generator to copy the userType field from the motus API validation call to the user_data portion of the ticket.

  • this way, most data API calls will use the cheaper authToken method, when called by the motusClient package, but occasional uses from wrappers for the status API will be able to use a single authentication token for all calls

  • API calls with JSON payloads don't have to attach cookie headers

This would all benefit from a comprehensive rethink, but expediency suggests the hybrid solution as the way to go.

A single motusServer function, validate_request() can test requests with JSON payloads having authToken, and if the latter contains a ! character, treat it as a ticket, rather than a token.