high-templar 3.1.0

A python framework for creating a server which handles websockets for an existing API

A python framework for creating a stateful server which handles websocket functionality for an existing HTTP only API.

Flow

• A client opens a websocket connection with a High-templar instance.

• The HT instance proxies the request to the API, which in turn handles authentication and provides a list of rooms.

• The HT instance tells the client what rooms he is allowed to subscribe to.

• The client subscribes to one or more rooms

• When receiving a trigger from the API, the HT instance publishes the received data to the specified rooms.

Installation

pip install -Ur requirements.txt
pip install high-templar

# Install rabbitmq and create a user.
apt install rabbitmq-server
rabbitmqctl add_user rabbitmq rabbitmq
rabbitmqctl set_user_tags rabbitmq administrator
rabbitmqctl set_permissions -p / rabbitmq ".*" ".*" ".*"

# Take a look at `install` folder for examples for systemd.

Motivation

This project is created for handling websockets for a django instance. Django doesn’t support websockets out of the box. To add websocket support to Django, one can either monkey patch the Django WSGI with gevent, or use django-channels which requires a lot of configuration and needs you to manage its workers.

High-templar uses a similar approach to django-channels, but uses internal HTTP requests to communicate with the existing Django instance. High-templar keeps track of the active websocket connections, which allows the Django instance to remain stateless.

Architecture

The Rabbitmq rewrite made it possible

2 concepts are fundamental:

1. Connection: a single websocket bi-directional data pipe connection.

2. Room: an authenticated place where data is send from the server.

Normally only 1 connection is created during the entire session, but many, many rooms are subscribed to using this single connection. When a connection is created, the server responds with the allowed rooms for that user. A room is identified by a hash, and upon subscribing the client needs to specify a unique requestId that identifies the subscription to that room. That requestId can be used to match messages send from the server to a specific room. It is also used to unsubscribe from a room.

Interfaces

Starting a connection

Starting up a connection

When creating a connection, and authentication can be done:

Response:

{
    "is_authenticated": True,
    "allowed_rooms": [{
        "target": "message",
        "customer": "1"
    }]
}

When creating a connection, and authentication can not be done:

Response:

{
    "is_authenticated": False
}

Subscribing to a room

Request:

{
    "type": "subscribe",
    "room": {
        "target": "message",
        "customer": "1"
    },
    "requestId": "1"
}

Response when you have permission:

{ "code": "success" }

Response when you don’t have permission or the room doesn’t exist:

{
    "code": "error",
    "message": "room-not-found"
}

TODO: document unsubscribe

Room permissions

The initial message send from the server contains an allowed_rooms key. This allowed_rooms key determines which rooms which the client can subscribe to. Upon subscribing, the server checks if the client is allowed into the room, but once connected no futher permission checking is done. An example server response upon creating a connection:

{
    "is_authenticated": True,
    "allowed_rooms": [{
        "room": "user-login",
        "department": "finance"
    }, {
        "room": "user-logout",
        "department": "finance"
    }, {
        "target": "chat-create",
        "customer": "*"
    }, {
        "target": "chat-update",
        "customer": "*"
    }]
}

The key / value pairs have no meaning, other then identifying a room. An exception is the special * character, which means that anything will match in place of that character. For the response above, it means the client can connect to the 4 rooms described in allowed_rooms, but also to:

{
    "type": "subscribe",
    "room": {
        "target": "chat-create",
        "customer": "*"
    },
    "requestId": "1"
}

{
    "type": "subscribe",
    "room": {
        "target": "chat-create",
        "customer": "1"
    },
    "requestId": "2"
}

{
    "type": "subscribe",
    "room": {
        "target": "chat-create",
        "customer": "2"
    },
    "requestId": "3"
}

Sending data to a room

To send data to a room, send a POST request to the server:

{
    [
        {
            "target": "chat-create",
            "customer": "*"
        },
        {
            "target": "chat-create",
            "customer": "1"
        },
        {
            "target": "chat-create",
            "customer": "2"
        }
    ],
    "data": "Example text body"
}

Using the *, we can cut 2 rooms. So this is the exactly the same as:

{
    [
        {
            "target": "chat-create",
            "customer": "*"
        }
    ],
    "data": "Example text body"
}

TODO: Implement this TODO: Add test for trigger http endpoint

Ping pong

The frontend can send a ping message to check if the websocket connection is still working. HT will send a pong message if the connection is still open

Request:

ping

Response:

pong

Tests

Run high templar first: ./run

After it is started, you can run all tests: ./test

Or run a specific test: ./test -v tests/tests/test_unsubscribe.py::TestUnSubscribe::test_unsubscribe_to_room

Origin

This repository is based on archon. Archon is a framework for creating full fledged websocket based CRUD APIs. High-templar is only half the framework of Archon, as it relies on an existing API and only provides pubsub.