Web Portal

From Spire Trading Inc.
Revision as of 19:49, 27 May 2026 by Kamal (talk | contribs) (Created page with "The Web Portal provides web-based access to account management and administrative functions through both a web API and an interactive HTML interface. It serves as the primary...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The Web Portal provides web-based access to account management and administrative functions through both a web API and an interactive HTML interface. It serves as the primary user interface for creating and managing trading accounts, configuring market data entitlements, defining compliance rules, setting risk parameters, and monitoring account activity. By aggregating functionality from multiple backend services, the Web Portal enables administrators and managers to perform operational tasks through a unified web application.

The Web Portal integrates with the Service Locator for authentication and communicates with the Administration Server, Compliance Server, Risk Server, and Order Execution Server to provide comprehensive account management capabilities.

Configuration

The Web Portal is configured via a YAML file with two top-level sections: server and service_locator, plus an optional url field. Below is the structure of the configuration file with example values:

server:
  # Primary network interface and port the Web Portal binds to.
  interface: "0.0.0.0:8080"
  # List of addresses the server is reachable at (for registration with Service Locator).
  # Typically includes both public-facing and local addresses.
  addresses: ["198.51.100.5:8080", "10.0.0.5:8080"]

service_locator:
  # The address of the Service Locator (host:port).
  address: "10.0.0.5:20000"
  # The account username used by the Web Portal to authenticate with the Service Locator.
  username: web_portal
  # The password for the Web Portal's Service Locator account.
  password: [REQUIRED]

# Optional public URL registered with the Service Locator (defaults to http://<interface>).
url: "https://portal.example.com"

A setup.py script is provided to generate the final config.yml from the config.default.yml template. Usage:

  --local 0.0.0.0           # Local interface (default: auto-detected IP)
  --world 198.51.100.5      # Global/public interface (optional)
  --address 10.0.0.5:20000  # Service Locator address (default: local_interface:20000)
  --password [REQUIRED]     # Service password for authentication

Capabilities

The Web Portal provides access to the following administrative and operational capabilities:

  • Configure account permissions and access controls
  • Set account roles (trader, manager, administrator, service)
  • Configure per-venue and per-message-type permissions
  • Assign rules to accounts, groups, or directories
  • Configure rule states (active, passive, disabled)

Permissions

The Web Portal enforces permissions based on account roles:

  • Administrators have full access to all management functions
  • Managers can manage accounts within their assigned groups
  • Traders can view their own account details and activity
  • Service accounts have restricted programmatic access

All operations are authenticated through the Service Locator and logged for audit purposes.

Management

The Web Portal is controlled using three operational scripts: start.sh, stop.sh, and check.sh.

start.sh

  • Exits immediately if the server is already running.
  • Creates a logs/ directory if necessary.
  • Moves any existing srv_*.log files into logs/.
  • Starts the WebPortal process in the background.
  • Reads network interfaces from config.yml and waits until the server is listening on at least one configured address.

This ensures the server is fully initialized before the script exits.

stop.sh

  • Sends SIGINT to request a graceful shutdown.
  • Waits for termination using exponential backoff (up to 300 seconds).
  • Sends SIGKILL if the server fails to stop cleanly.
  • Appends a forced-termination message to the most recent log file (if applicable).

This guarantees consistent shutdown behavior across normal and exceptional conditions.

check.sh

The check.sh script verifies whether the server is currently running by inspecting the PID recorded in pid.lock and testing whether the associated process exists.

Logging

Upon startup, older log files are moved into the logs/ directory.