mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-06 07:26:43 -04:00
Jeffrey Dallatezza
1d08167ebd
# Description of Changes This adds a new system table to store the jwt payloads of connected clients. I'm planning to use this system table to expose client claims to modules in subsequent PRs. The new table is called `st_connection_credentials`. It is a **private** system table which stores a mapping from `connection_id` to `jwt_payload`. Note that a jwt payload is a json representation of the clients claims, not a fully signed token. The times when we need to insert and delete these rows closely mirrors that of the existing `st_client` table, with 1.5 exceptions: 1. We weren't previously inserting to `st_client` until after the `OnConnect` reducer ran (even though it was in the same transaction). We want `st_connection_credentials` to be populated before calling the reducer, so that the reducer can use it get the credentials, so I made a change to insert to `st_client` and `st_connection_credentials` before calling the reducer. 2. This difference has not actualized, but when clients start sending refresh tokens, we will probably need to update the credentials stored in this table. This also enforces uniqueness of connection ids. A duplicate connection id will now make the on-connect reducer fail (since it will violate uniqueness when trying to insert to `st_connection_credentials`). # Expected complexity level and risk 2.5 Adding a system table is a bit risky. This is almost rollback safe, with one annoying case that is worth calling out: If a database is created with this system table, opening it with an older version of spacetimedb will only work if there is a snapshot of the database. If we try to load a table without a snapshot, replaying will fail on the first row for that table. This is because we don't write the table schema information to the commit log when creating a database. In practice, this is unlikely to be an issue, because new databases asynchronously trigger a snapshot immediately after creation. Migrating existing databases will be fine. On startup this will detect that there is a missing system table, and add it in a way that writes it to the commit log. Since it is in the commit log, we can open the database with an older version and still understand the data for that table. # Testing There are unit tests that cover opening a database created with an older version (which doesn't have this table). I manually tested opening a migrated database with an older version of spacetimedb.
⚠️ Internal Crate ⚠️
This crate is intended for internal use only. It is not stable and may change without notice.