TODO_NAME

A simple CMake target is provided to build the project in Debug mode, run all of the unit tests, and then generate a coverage report using LLVM's llvm-profdata/llvm-cov tools. It will only be available when the CMAKE_BUILD_TYPE is Debug (the tests themselves are only added in Debug as well).

mkdir -p build && cd build              # configure normally (debug is default)
cmake ..
cmake --build . --target coverage       # build, run tests, and create report

The HTML output will be written to coverage_html/ and a brief text summary is in coverage.txt. Raw profile files are created under the build directory and are ignored by git (see .gitignore).

A handful of command-line flags control the service; the most important ones are:

• --host / --port – Network address to bind to.

• --webroot – Path to the static web UI files.

• --keys – JSON file containing the PlayStation key material.

• --max_upload_mb – Maximum upload body size (default 512).

• --job_ttl_minutes – How long completed/errored jobs are retained.

• --api_key – If non-empty the server requires every request under /api/ to include an X-Api-Key header matching this value. This simple shared-secret mechanism provides a lightweight way to restrict access without building a full user database. Set the flag via an environment variable or command-line argument in containers.

• /status and /auth – The server maps these paths directly to the corresponding HTML pages in the web root (status.html and auth.html respectively). This mimics a simple mod_rewrite rule so clients can use clean endpoints instead of typing the full filenames. The mappings are only active for GET requests and are handled before the static-file machinery.

  When the key is set, the server now rejects unauthorized API requests as soon as the HTTP headers are received. This prevents clients from wasting bandwidth (or filling the temporary upload directory) by sending large files that will just be refused. The controller methods still perform a secondary check for defence‑in‑depth, but the early check is applied before any multipart body data is parsed. The server will also close the connection immediately after responding; if a client uses the Expect: 100-continue mechanism it will therefore never begin uploading the body. Without that header or a prior validity check the client may still push the payload until it notices the connection drop. To address this the browser UI (and other clients such as the CLI) perform a quick authentication ping (GET /api/auth) before launching any large upload; if the key is missing or incorrect the transfer is never started.

  Users authenticate via the dedicated /auth entry screen instead. The successful key is kept in sessionStorage and injected automatically into every API request. If the stored key is missing or invalid the main interface will redirect to /auth immediately upon loading.

  For efficiency the web UI now caches the result of the auth check and skips subsequent pings as long as the session API key (stored by /auth) remains unchanged. The cache is flushed automatically when that value is replaced by a fresh login.

Example:

./bin/main --host=127.0.0.1 --port=8080 --keys=keys.json --api_key="s3cr3tk3Yn05haR3"