The same server now can handle multiple logical channels, on which the
transmitter logic runs independently. That is, while previously a single
message would be in transmitting state at a time, now multiple messages
can be in transmitting state as long as they belong to distinct logical
channels.
The supported channels each have different permissions. The user channel
is where users can post, get, and delete messages as needed. In
contrast, the other channels do not grant all permissions to users. Some
are read-only (users can get but not post) and there is a channel (the
auth channel) on which users have no permissions (neither get nor post).
For the channels on which users do not have all permissions (get, post,
and delete), this patch adds admin-specific routes, which are prefixed
by /admin/. The /admin/ route is protected via SSL in production and
allows the admin host to send GET/POST/DELETE requests normally. Hence,
for instance, the admin host can post a message on the auth channel
(with POST /admin/order) and read it (with GET /admin/order) for
transmission over satellite, whereas regulars cannot. With this scheme,
the auth channel messages are accessible exclusively over satellite (and
not over the internet).
The admin routes were added to the following endpoints:
- /order/<uuid> (GET and DELETE requests)
- /order (POST request)
- /orders/<state> (GET request)
- /message/<tx_seq_num> (GET request)
The messages posted by the admin are not paid, so this patch removes the
requirement of invoice generation and payment. Only paid orders now
generate an invoice. Thus, the POST request to the /order/ endpoint does
not return an invoice for non-paid (admin-only) messages.
Also, this patch updates the queue page to display the orders separately
for each channel. The query string channel parameter determines which
channel the page shows.
Finally, this patch updates the events published into the Redis db on
transmission. The event includes the corresponding logical channel so
that SSE events can be subscribed independently for each channel.
Flask-RESTful returns a JSON response by default when returning a
dictionary. It's not necessary to dump the returning dictionary into a
JSON-serialized string. Otherwise, the client will see a string response
instead of a JSON response.
Users can provide a list of regions to POST /order requests. This list
indicates on which regions the order should be transmitted. It also
determines the expected transmission and reception confirmations.
The new server implementation in Python implements request validation
using the Marshamallow package. With that, some requests are validated
directly by the marshmallow validator and do not return custom error
codes. Drop those error codes and other unused ones. Review the README
docs accordingly.
- Preserve the SQLite database and use SQLAlchemy to wrap db
interactions.
- Use Alembic for database migrations.
- Organize all the python modules on the new server/ directory.
- Use pytest for unit tests and organize test modules at server/tests/.
