mirror of
https://github.com/clockworklabs/SpacetimeDB.git
synced 2026-05-15 04:08:02 -04:00
bf37b2947b
# Description of Changes This exposes JWT claims for csharp modules, similar to how they are exposed to rust modules in https://github.com/clockworklabs/SpacetimeDB/pull/3288. This adds the new types `AuthCtx` and `JwtClaims`, and adds an `AuthCtx` to the `ReducerContext`. `AuthCtx` represents the credentials associated with the request, and `JwtClaims` represents a jwt token. One difference from the rust version is that I didn't create helpers to build an `AuthCtx` from a jwt payload. The reason is that we would need to be able to compute the identity from the payload claims, which requires a blake3 hash implementation. The first two c# libraries I found had issues at runtime ([Blake3](https://www.nuget.org/packages/Blake3) is wrapping a rust implementation, and [HashifyNet](https://github.com/Deskasoft/HashifyNET/tree/main/HashifyNet/Algorithms/Blake3) seems to be broken by our trimming because it uses reflection heavily). I can look into taking the implementation from `HashifyNet`, since it is MIT licensed, but I don't think we need to block merging on that. # API and ABI breaking changes This adds the new types `AuthCtx` and `JwtClaims`, and adds an `AuthCtx` to the `ReducerContext`. This also adds a csharp wrapper for the get_jwt ABI function added in https://github.com/clockworklabs/SpacetimeDB/pull/3288. # Expected complexity level and risk 2. # Testing This has a very minimal unit test of JwtClaims. I manually tested using this locally with the csharp quickstart, and I was able to print jwt tokens inside the module.
SpacetimeDB.Runtime
This project contains the core SpacetimeDB SATS typesystem, attributes for the codegen as well as runtime bindings for SpacetimeDB WebAssembly modules.
The runtime bindings are currently implementing via Wasi.Sdk package, which is a .NET implementation of the WASI standard. This is likely to change in the future.
While not really documented, it allows to build raw WebAssembly modules with custom bindings as well, which is what we're using here. The process is somewhat complicated, but here are the steps:
bindings.cdeclares raw C bindings to the SpacetimeDB FFI imports and marks them with attributes like__attribute__((import_module("spacetime"), import_name("_insert")))that make them WebAssembly imports. (unfortunately, function name duplication is currently unavoidable)bindings.cimplements a bunch of Mono-compatible wrappers that convert between Mono types and raw types expected by the SpacetimeDB FFI and invoke corresponding raw bindings.Runtime.csdeclares corresponding functions with compatible signatures for Mono-compatible wrappers to attach to. It marks them all with[MethodImpl(MethodImplOptions.InternalCall)].bindings.cattaches all those Mono-compatible wrappers to their C# declarations in amono_stdb_attach_bindingsfunction.bindings.cadds FFI-compatible exports that search for a method by assembly name, namespace, class name and a method name in the Mono runtime and invoke it. Those exports are marked with attributes like__attribute__((export_name("__call_reducer__")))so that they're exported from Wasm by the linker.- Finally,
bindings.cimplements no-op shims for all the WASI APIs so that they're linked internally and not attempted to be imported from the runtime itself.
The result is a WebAssembly module FFI-compatible with SpacetimeDB and with no WASI imports, which is what we need.
Regenerating RawModuleDef
To regenenerate the Autogen folder, run:
cargo run -p spacetimedb-codegen --example regen-csharp-moduledef