Sekiban.Cloud.Client 1.0.0-preview.1

Sekiban.Cloud.Client

SKS-G770: Credentialed ISekibanExecutor client for Sekiban Cloud (managed) and credentialed self-hosted Sekiban Runtime.

This is the credentialed, multi-tenant client: credentials are mandatory and the handler fails fast when they are missing (no silent no-auth fallback). For no-auth, single-tenant access use the OSS Sekiban.Dcb.WasmRuntime.Remote client instead — the distinguishing axis is credentialed vs no-auth, not cloud vs local.

Provides AddSekibanCloudExecutor — a single DI registration call that wires up the ISekibanExecutor interface from IConfiguration (user-secrets / environment variables) with no application code branches required.

Minimal C# Setup

// Program.cs — Sekiban Cloud client registration.
// Reads all four SekibanCloud:* keys from IConfiguration (user-secrets / env vars).

services.AddSekibanCloudExecutor(
    domainTypes: MyDomainTypes.Create(),     // your DcbDomainTypes
    configuration: configuration             // IConfiguration root
);

That is the entire setup. Application command and query code is identical across backends — the only difference is which executor is registered (see the canonical explicit-if sample in Sekiban.Dcb.Runtime.ConfigurationBootstrapSample).

Configuration Keys

All four keys are read from the SekibanCloud configuration section (the legacy SaasRuntime section is still read for one version, logged as deprecated). Use user-secrets for local development, environment variables for CI/deployment.

Set via user-secrets (local development)

cd samples/YourApp
dotnet user-secrets set "SekibanCloud:BaseUrl"          "http://127.0.0.1:5201"
dotnet user-secrets set "SekibanCloud:ServiceId"        "svc-your-service"
dotnet user-secrets set "SekibanCloud:CredentialId"     "cred-your-credential"
dotnet user-secrets set "SekibanCloud:CredentialSecret" "<secret-from-management-api>"

The credential secret is never written to any source file. Use dotnet user-secrets for local development and a secret provider (e.g. Azure Key Vault) for production.

Set via environment variables (CI / deployment)

export SEKIBANCLOUD__BASEURL="https://runtime.example.com"
export SEKIBANCLOUD__SERVICEID="svc-your-service"
export SEKIBANCLOUD__CREDENTIALID="cred-your-credential"
export SEKIBANCLOUD__CREDENTIALSECRET="<secret>"

Explicit backend selection

Choose the backend with an explicit if/#if in your app code — no config-magic auto-branch. The canonical sample selects among three options, each failing fast on its own misconfiguration:

// InMemory (local dev), Sekiban Cloud (credentialed), or no-auth self-host.
if (backend == Backend.InMemory)
    services.AddSingleton<ISekibanExecutor>(_ => new InMemoryDcbExecutor(domainTypes));
else if (backend == Backend.SekibanCloud)
    services.AddSekibanCloudExecutor(domainTypes, configuration);   // credentialed, fail-fast
// else if (backend == Backend.RemoteNoAuth)
//     /* OSS Sekiban.Dcb.WasmRuntime.Remote — no credentials */

Public API Surface

Security Constraints

• CredentialSecret is never logged — the handler log statement emits only non-secret fields.
• Exception messages from validation also omit the secret value.
• Credentials are mandatory: the handler throws on missing CredentialId/CredentialSecret rather than producing a silent 401/403 or falling back to no-auth.
• Use dotnet user-secrets for local dev; never commit secrets to source control.

One-Command Local Provisioning

When working with the full local stack (management API + runtime):

bash samples/SekibanAsAService.SampleApp/provision-local-dev.sh

This provisions a service + credential and writes the four SekibanCloud:* user-secrets in a single step. The credential secret is written only to dotnet user-secrets (never to any file or log).