* refactor(auth): remove the vestigial per-author script permission plumbing #7975 is closed won't-do: authoring a workflow is a trusted act, and a per-author gate would not change what a script can do once it runs. The host switch stays the control, and it is per language, so an untrusted author gets a host with the switch off rather than a permission. That settles what the code was still half-carrying. WorkflowDefinitionScriptAuthorizationService took a ClaimsPrincipal it never read, and could return a MissingPermission reason nothing produced; two call sites branched on that reason to send a 403 that could not happen. The expression-descriptor endpoint kept a map from expression type to per-author permission whose values went unused even before the permissions were retired -- it only ever tested membership, and the decision was always IsBrowsable. Each of these reads as an authorization gate to anyone scanning the file, and none of them is one. The principal, the unreachable reason, and both dead branches are gone. The map becomes a set of the expression types the host can switch off, which is what it was actually being used as. Behaviour is unchanged: the only failure is a language the host disabled, which is a property of the deployment and so a 400 naming the switch, never a 403. PermissionNames loses ExecuteCSharpExpressions and ExecutePythonExpressions, which existed only for that map and the test mirroring it. Five other legacy constants there are also unreferenced but belong to other modules; they are left alone rather than swept up here. Two tests asserting the host-and-user case were exact duplicates of the host-only case once the principal stopped mattering, so they go with it. The migration guide said deployments lose per-author granularity "until #7975 lands" and advised disabling host code until then. That promise is withdrawn and replaced with the actual guidance. Closes #7975 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(wiki): drop the retired exec:* permissions from the scripting guide Review found doc/wiki/expressions-and-scripting.md still telling operators that API callers "must have the exec:csharp-expressions permission" to author, publish, dispatch or execute workflows containing C#, and the same for Python. Those permissions no longer exist, so the instruction cannot be followed and describes a gate that is not there. Both sections now say what is actually true: the host switch is the whole control, there is no per-caller permission because a workflow runs under the server's authority rather than the caller's, and an untrusted author gets a host with the switch off. The switches are noted as independent, since enabling Python while leaving C# off is a real posture. My earlier sweep searched for the issue number rather than the permission strings, which is why this file was missed. Refs #7975 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| activities-and-authoring.md | ||
| architecture.md | ||
| bpmn-workflows.md | ||
| build-run-operate.md | ||
| diagnostics-console-logs.md | ||
| diagnostics-structured-logs.md | ||
| expressions-and-scripting.md | ||
| extension-guide.md | ||
| health-checks.md | ||
| http-scheduling-resilience.md | ||
| identity-tenancy-security.md | ||
| module-system.md | ||
| opentelemetry-workflows.md | ||
| output-converters.md | ||
| persistence.md | ||
| README.md | ||
| repository-map.md | ||
| specs-and-adrs.md | ||
| testing-guide.md | ||
| workflow-api.md | ||
| workflow-core.md | ||
| workflow-management.md | ||
| workflow-runtime.md | ||
Elsa Core Wiki
This wiki is a repo-local, code-grounded map of Elsa Core. It is intended for contributors who need the same kind of fast orientation that a DeepWiki-style generated wiki gives: what the system is, where the important code lives, how the pieces connect, and how to safely extend or test them.
The source of truth is still the code, specs, ADRs, and tests. Each page links back to the relevant files so you can jump from explanation to implementation.
Start Here
Elsa Core is a modular .NET workflow engine. The main solution is Elsa.sln. Production code lives under src, tests under test, specifications under specs, and architecture decisions under doc/adr.
The shortest mental model:
- An application calls
services.AddElsa(...). - Elsa builds an
IModuleand configures feature objects. - Features register services, activities, API endpoints, middleware, hosted services, and persistence stores.
- Workflow definitions are created by code, JSON, imported files, or providers.
- The runtime starts, resumes, dispatches, and persists workflow instances.
- APIs, SignalR hubs, HTTP endpoint activities, diagnostics, and persistence packages layer around that core.
flowchart LR
App["Host app"] --> Module["Elsa module system"]
Module --> Core["Workflow core"]
Module --> Management["Workflow management"]
Module --> Runtime["Workflow runtime"]
Module --> Api["Workflow API"]
Module --> Extensions["HTTP, Scheduling, Expressions, Identity, Tenants"]
Management --> Persistence["Stores / EF Core providers"]
Runtime --> Persistence
Runtime --> Logs["Execution logs and diagnostics"]
Api --> Studio["Elsa Studio / API clients"]
Page Map
| Page | Use it for |
|---|---|
| Repository Map | Top-level folders, projects, and where to look first. |
| Architecture | The main system layers and request/execution flow. |
| Module System | How IModule, FeatureBase, feature dependencies, and shell features work. |
| Workflow Core | Activities, execution contexts, pipelines, variables, bookmarks, graphs, and flowchart execution. |
| Workflow Management | Workflow definitions, instances, import/export, materializers, validation, and activity descriptors. |
| Workflow Runtime | Dispatch, triggers, bookmarks, queues, background activity scheduling, graceful shutdown, and recovery. |
| Workflow API | FastEndpoints, route prefixing, API categories, SignalR, and client-facing contracts. |
| Activities And Authoring | How workflows are authored in C#, JSON, ElsaScript, and host methods. |
| Output Converters | How to register, configure, validate, discover, and operate bound-value converters. |
| Expressions And Scripting | Expression evaluators and language feature packages. |
| HTTP, Scheduling, And Resilience | Inbound HTTP workflows, outbound HTTP, scheduled triggers, and resilience strategies. |
| Persistence | In-memory stores, EF Core stores, provider packages, migrations, and multi-provider rules. |
| Diagnostics Structured Logs | ILogger capture, live feed, REST/SignalR surface, redaction, and SQLite persistence. |
| Diagnostics Console Logs | Raw stdout/stderr capture, live feed, REST/SignalR surface, and redaction. |
| Health Checks | Elsa runtime readiness probes, liveness/readiness mapping, and Kubernetes probe guidance. |
| Identity, Tenancy, And Security | Users, applications, roles, API keys, tenant resolution, and authorization touch points. |
| Testing Guide | Test project layout, fixture choices, and targeted commands. |
| Extension Guide | How to add features, activities, expression providers, stores, endpoints, and ingress sources. |
| OpenTelemetry Workflow Instrumentation | First-party workflow and activity traces and metrics emitted through System.Diagnostics. |
| Specs And ADRs | How current specs and ADRs explain design intent. |
| Build, Run, And Operate | Build commands, sample hosts, runtime knobs, Docker notes, and operational endpoints. |
Source Landmarks
- Main public entry: src/modules/Elsa/Extensions/DependencyInjectionExtensions.cs
- Default umbrella feature: src/modules/Elsa/Features/ElsaFeature.cs
- Module implementation: src/common/Elsa.Features/Implementations/Module.cs
- Core workflow feature: src/modules/Elsa.Workflows.Core/Features/WorkflowsFeature.cs
- Management feature: src/modules/Elsa.Workflows.Management/Features/WorkflowManagementFeature.cs
- Runtime feature: src/modules/Elsa.Workflows.Runtime/Features/WorkflowRuntimeFeature.cs
- API feature: src/modules/Elsa.Workflows.Api/Features/WorkflowsApiFeature.cs
- Reference server: src/apps/Elsa.Server.Web/Program.cs
- Structured-log persistence design: specs/005-structured-log-persistence/plan.md
Contributor Workflow
Use targeted reads first, then targeted tests. For most changes, start with the relevant module page, inspect the linked feature class and contracts, add or update tests in the matching test/unit, test/integration, or test/component project, and run the narrowest dotnet test command that proves the behavior.
When changing public behavior, update the related README, spec quickstart, or wiki page in the same PR. This repository is strongly modular, so the best changes keep ownership boundaries clear.