34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# Personal Authentication Mod Flow
|
|
|
|
This document details the modifications and features integrated within `spt-launcher` and `server-csharp` to support the custom Personal Authentication Mod.
|
|
|
|
## What is Personal Authentication?
|
|
Unlike the vanilla SPT launcher which assumes 1 user = 1 machine, Personal Authentication enables multiple isolated accounts. Users register and log in to uniquely generated session IDs via `AuthRouter.cs` hooking into `LauncherCallbacks`.
|
|
|
|
## The `server-csharp` Modifications:
|
|
The server's default JSON payload parsing was too strict regarding unmapped JSON structures (like adding a `password` field).
|
|
|
|
We addressed this by updating the base interface in `SPTarkov.Server.Core`:
|
|
```csharp
|
|
namespace SPTarkov.Server.Core.Models.Eft.Launcher;
|
|
|
|
public record LoginRequestData : IRequestData
|
|
{
|
|
[JsonPropertyName("username")]
|
|
public string? Username { get; set; }
|
|
|
|
[JsonPropertyName("password")]
|
|
public string? Password { get; set; }
|
|
}
|
|
```
|
|
Now, `LoginRequestData` natively accepts passwords, allowing Harmony Patches on `LauncherCallbacks.Login` and `LauncherCallbacks.Register` to validate against the database gracefully.
|
|
|
|
## Custom Token Session vs Default Random Session Strings
|
|
Vanilla SPT creates a random GUID session variable that is used loosely.
|
|
With SSO:
|
|
1. `spt-launcher` initiates an HTTP POST `/launcher/profile/login` with `username` and `password`.
|
|
2. The Database (`DatabaseManager.cs`) verifies credentials against PostgreSQL passwords (hashed).
|
|
3. Returns a specific `SessionID` mapped directly to that User ID.
|
|
4. The launcher preserves this ID in cookies and local cache storage.
|
|
5. Sub-requests (Start Client, Fetch Match Profiles) utilize this single, constant Session ID instead of performing a secondary manual profile scan discovery via `/launcher/profiles`.
|