Overview

This document describes the management system for the Massive MapTool Server. The MMS is a Linux-based MapTool configuration (currently Ubuntu 20.04 LTS) which supports individual passwords for each MapTool client, whether GM or player.

Background

MapTool includes two types of connected clients, either GM or Player. There is one password for GMs and another for Players. Whichever password the client uses determines what their role is when they connect.

This setup doesn’t scale well for the number of connected clients. When there are only four or five GMs and Players, it’s not too much trouble to change the password when the authorized list of clients changes… Simply send the new password to clients who are still allowed to connect. However, with a number of clients measured in the tens or hundreds, sending a new password every time a single client drops out of a campaign is impractical.

Implementation

While we wait for MapTool to support a new scheme, I’ve created both a virtual machine and a Docker image that can run in the cloud. These containers use SSH tunneling to implement per-client authentication. This document describes what the final system will support (right now these items are a manual process).

  • Each user must register (ie, create an account on) the MMS system.

  • Each client then creates a public/private key pair (MMS will provide an option for this).

  • The public key is stored within the MMS for the user, and the private key is kept on their system.

  • A user with appropriate privileges assigns a role to the public key. (See [Roles], below.)

  • When a client connects to MMS using that key, they are granted the access specified by the role.

  • The roles are currently Manager, GM, and Player.

  • Users may use their key to connect to a given MapTool server, but they still require the GM or Player password to identify their level of access to MapTool itself (the roles discussed here are for access to MMS).

When a client connects using a particular key, they are granted access to any campaigns that have been associated with that key. Each key is assigned a role for a particular campaign, allowing a single key to be used for different purposes in different campaigns. A player may upload/create a single key and use it to play in multiple campaigns. Similarly, a GM may upload a single key and use it to run one or more campaign, and play in zero or more different campaigns.

The administrator may assign any role to any user on the system, and may similarly assign campaigns to managers. Managers may assign GMs to the campaigns they want to run. GMs may assign other GMs to their campaign. Both managers and GMs may assign players to a campaign for which they are responsible. More details of each role are described in the next section.

Roles

There are four roles that users may have within the system. (The last one, User, isn’t a Role so much as an alias that encompasses all Roles, but this seems the logical place to define it.) These roles are applied to a given public key for a User; thus, a User may act in different roles in different parts of the system.

  1. Administrator

    This role is the administrator for the system and has access to all other components and controls. The Administrator is primarily responsible for creating Campaigns and assigning Managers to those Campaigns. Currently, I am the only such administrator.

  2. Manager

    This role is assigned to a Key by the Administrator to delegate authority over a portion of the system. The Administrator will assign Campaigns to the Manager so that the Manager may then assign GMs. Both Managers and GMs may assign Players. Managers may also add/remove other Users as Managers over the Campaigns in their portfolio, although the original Manager for a Campaign may only be removed by the Administrator.

    Managers are not given the ability to connect to the MapTool server in any capacity. (However, they can assign their Key the additional role of GM or Player, if they wish.)

  3. GM

    This role is assigned to a Key by the Administrator, or by the Manager of a Campaign. The GM may connect to the MapTool server as "GM". The GM may also assign the Player role to a public key for any Campaign the GM controls.

  4. Player

    This role is assigned to a public key by the Administrator, by the Manager of a Campaign, or by the GM of a Campaign. The Player may connect to the MapTool server as "Player". A Player may delete any of their public keys and will subsequently lose access to the associated Campaign. A Player may update any of their public keys without losing the role that the key was assigned. (This allows a Player to create a new Key and upload it to replace one that may have been compromised.)

  5. User (not really a Role)

    This is not a separate role, but a group of all of them. It is a shortcut way of referring to anyone with an account on the MMS system.

System Design

My initial thought is a static website that feeds the React-based app to the browser.

Whenever the user executes an operation, a REST-like call is made to the web server where a Python Flask script makes the necessary changes.

This has the benefit of allowing a separate Python daemon to run with a connection always open to the database, so that the Flask app can make a quick connection. Or, if Python doesn’t allow connection pooling between processes using a common module (look this up), see if the Python script can run as a CGI program with the web server maintaining the connection pool.

Note

I’ve changed my thinking on this after discussing other AWS services with a buddy of mine. I’m now considering a static website that feeds a React-based single-page web app to the browser. After the browser authenticates, it uses REST calls to AWS Lambda services to accomplish the tasks listed below. The Lambda services all write to a database, which the EC2 instance reads at startup.

There should be two additional static links:

  1. One that allows any Role other than Player to force a database read for keys. This allows a Manager or GM to add a late entry Player.

  2. And one for Administrators and Managers that forces the static website to execute a git pull and the browser SPA to refresh. This allows an update of the server on the fly.

User Stories

These user stories are described in terms of the MapTool gaming system and use terminology specific to that system. For example, a "campaign" is known to MapTool users as an ongoing story in which Players are the main story characters, and the GMs are running the game.

The backend will implement the following user stories:

  • Users can register with name and email address.

  • Users must own at least one public key. Until they do, there will be no visibility into system data. They may upload a Key or have MMS generate one for them.

  • Each Key a User has defined can be assigned a Role for a given Campaign.

    • This allows a single user to be a Player in one Campaign, and a GM in another, by having different roles assigned to the same Key for different Campaigns.

    • When a User deletes a Key, their associated Roles are deleted.

    • Managers and GMs can be notified when Roles are added or removed for Campaigns in their portfolio.

    • Users may ping a Manager or GM to ask for access to a given Campaign.

    • Managers and GMs may invite Users to a Campaign in their portfolio.

  • Managers can create Campaigns and GMs. (Campaign creation is currently restricted to Administrators until this project is out of beta.)

  • Managers can assign GMs to Campaigns they control (called their portfolio).

  • Managers and GMs can terminate a player’s game session immediately for Campaigns in their portfolio. This does not disable the Key or the Role, and the User may immediately login again.

  • Players can manage which campaigns they are enrolled in (view and drop only). There may be other visibility as well, such the Managers and GMs, and possibly other Players.

Diagrams

This begins the technical documentation for how the system will be built. These diagrams are SVG, so if your browser is too lame to display them properly, switch to a better one.

"Abandon all hope ye non-programmers who enter here."

1. Use Cases

2. Object Model

Sequence Diagrams

1. Add Key to System as Manager - Administrator

2. Create Campaign - Administrator

3. Add Campaign to Manager - Administrator, Manager

4. Add Key to Campaign as GM - Manager

5. Add Key to Campaign as Player - GM, Manager

6. Connect to Campaign - Player

7. Manage Access - all User types

REST-like URLs Used by MMS

(For future use.)