f6b27025a6
## Proposed changes Fixes #4857. The stack's log messages wrote network addresses (endpoint, discovery and reverse connect URLs, host names, IP addresses, ports), application and user identities, file paths and exception texts as plain parameters. Applications had no reliable way to keep them out of general-purpose logs. This PR replaces the stack's own redaction mechanism with the standard .NET [data classification and redaction](https://learn.microsoft.com/dotnet/core/extensions/data-redaction) packages. Each sensitive `[LoggerMessage]` parameter is classified. The application decides per classification what reaches its logs: erase it, replace it with an HMAC token so entries stay correlatable, or pass it through. ### Taxonomy `Opc.Ua.Redaction.OpcUaDataClassifications` defines the `OpcUa` taxonomy and one attribute per classification: | Classification | Used for | Parameters | |---|---|---| | `[NetworkAddress]` | URLs, host and domain names, IP/MAC addresses, end points, ports | 120 | | `[ApplicationIdentity]` | certificates, subject, issuer, thumbprint, ApplicationUri | 103 | | `[FilePath]` | file, directory and certificate store paths | 67 | | `[SensitiveText]` | exception or remote-supplied text passed as a parameter | 55 | | `[UserIdentity]` | user names, token subjects | 7 | Correlation ids (`ChannelId`, `SessionId`, ...), status codes and NodeIds stay unclassified. ### Pipeline and defaults - Opc.Ua.Core now references `Microsoft.Extensions.Telemetry(.Abstractions)` 10.11.0, so every project above Core uses the `Microsoft.Gen.Logging` generator. Opc.Ua.Client already did, through Http.Resilience. The packages ship net462 and netstandard2.0 builds, so net48 is supported. - **A plain `ILoggerFactory` logs `(null)` in place of classified values.** Classified values are only written by the redaction-aware logger. - The new `ILoggingBuilder.EnableOpcUaRedaction()` turns that logger on. It is `EnableRedaction()` with the discriminator off; otherwise every unredacted value gets `:ParamName` appended. `AddOpcUa().AddLogging(...)` and `DefaultTelemetry.Create(...)` call it, as do the samples, so they log the same information as before until redactors are registered. - `services.AddOpcUa()` alone does not change the host's logging. Generic-host apps call `builder.Logging.EnableOpcUaRedaction()`. This is documented as a behavior-breaking change in `docs/migrate/2.0.x/telemetry.md`. ### Obsolete API `Redact`, `RedactionWrapper<T>`, `IRedactionStrategy`, `RedactionStrategies` and `SimpleRedactionStrategy` are `[Obsolete]`. They still work, but the stack no longer uses them. ### Not classified - The `Exception` passed to a log call. Applications can drop exception messages with `LoggerEnrichmentOptions.IncludeExceptionMessage`. - Exception and `ServiceResult` message texts. - `ServiceResult`/`StatusCode` parameters and logged data values. - The few log calls whose level is decided at run time. - `Opc.Ua.Vision.OpenUsd`, which references only Opc.Ua.Types and cannot see the attributes. ### Generator behavior differences These are visible to log consumers and to tests: - `IFormattable` values such as `NodeId` are stored in the structured state as invariant strings, not as objects. - The generated log state is a thread-local object that is cleared after the call. - Classified values are pooled redactor objects, valid only during the `Log` call. Tests that inspected log state after the fact now capture it during the call. The shared `RecordingLoggerProvider` snapshots classified values. ## Related Issues - Fixes #4857 ## Types of changes - [ ] Bugfix (non-breaking change which fixes an issue) - [x] Enhancement (non-breaking change which adds functionality) - [ ] Test enhancement (non-breaking change to increase test coverage) - [x] Breaking change (fix or feature that would cause existing functionality to not work as expected; plain logger factories drop classified values) - [x] Documentation Update (if none of the other choices apply) ## Checklist - [x] I have read the CONTRIBUTING doc. - [x] I have signed the CLA. - [x] I ran tests locally with my changes, all passed. - [x] I fixed all failing tests in the CI pipelines. - [x] I fixed all introduced issues with CodeQL and LGTM. - [x] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [x] I have added necessary documentation (if appropriate). - [ ] Any dependent changes have been merged and published in downstream modules. ## Further comments New tests: - `LogClassificationCoverageTests` (Tools.Tests) scans all 104 stack assemblies and fails if an address, identity or path parameter of a `[LoggerMessage]` method is unclassified. - `DataClassificationLoggingTests` (Core.Tests) pins erasing and HMAC redaction, pass-through, the plain-factory drop, and both stack defaults. Local results on net10.0: | Suite | Passed | Failed | |---|---|---| | Core.Tests | 6,489 | 0 | | Client.Tests | 3,231 | 0 | | Tools.Tests | 7,210 | 0 | | PubSub.Tests | 1,536 | 0 | | Core.Diagnostics.Tests | 571 | 0 | | Configuration.Tests | 241 | 0 | - **Server.Tests:** the full run predates the final test fixes and had 12 failures. All 12 were in the fixtures fixed afterwards, which now pass: RoleStateBinding (45/45) and the FileDirectory and compatibility-logging fixtures (74/74 in total). The full Core.Tests and Server.Tests runs were not repeated after those fixes. - **Builds:** `UA.slnx` builds with 0 errors for net10.0 and net48, and the whitespace check passes. - **NativeAOT:** not confirmed locally, because the machine has no C++ linker. A trimmed publish of `Opc.Ua.Aot.Tests` reported no trim or AOT warnings from the stack, the new packages or the generated logging code; its only errors come from the TUnit test framework (`FSharp.Core` not found). The `aot-test` CI job has to confirm the native build. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
MachineTool and wireless-peripheral samples
These applications use the released typed MachineTool/WMTP runtime and clients. Their providers are explicitly simulated: no CNC instructions, Bluetooth pairing, radio driver, firmware installation or licence activation is performed.
Build both applications before starting the bounded server:
dotnet build samples\MachineTool\MachineToolServer\MachineToolServer.csproj -f net10.0
dotnet build samples\MachineTool\MachineToolClient\MachineToolClient.csproj -f net10.0
Run a secure, isolated workcell
In one terminal:
dotnet run --no-build --project samples\MachineTool\MachineToolServer -f net10.0 -- --mode mixed --advanced --instances 2 --seconds 120 --demo-trust --allow-commands --simulate-job Machine1
After its actual READY message, in another terminal:
dotnet run --no-build --project samples\MachineTool\MachineToolClient -f net10.0 -- --demo-trust
Default endpoint: opc.tcp://127.0.0.1:62558/MachineToolServer.
--port 0 chooses an available port; pass the reported URL to the client's
--endpoint. The server always binds loopback. --demo-trust is an explicit
local-only certificate exception; SignAndEncrypt/Basic256Sha256 remain
required. Without it, administer separate client/server trust stores with
--pki. Never deploy demo trust as production authorization.
--mode machine, wmtp and mixed select independent model closures.
Mandatory-only is the default; --advanced selects production/jobs/files and
all eight wireless measurement kinds, metadata and independent work/service
records. --instances 1..4 creates independent providers/stores for each
selected family.
The client discovers native identities, reads raw values/capabilities and complete bounded records, then makes one bounded observation. It preserves UA quality and acquisition time. Reports copy records rather than consuming them. A WMTP-only endpoint never fabricates a MachineTool.
Explicit commands
Every client mutation requires --target and --consent. The server separately
requires --advanced --demo-trust --allow-commands; --refuse-commands provides
a deterministic refusal scenario.
# Read the non-executable WorkMasters file and submit the declared ISA95 order.
dotnet run --no-build --project samples\MachineTool\MachineToolClient -f net10.0 -- --demo-trust --target Machine1 --read-files --command job-store-start --consent
# Accept a UInt32 trigger setting, then explicitly prove a second request is refused.
dotnet run --no-build --project samples\MachineTool\MachineToolClient -f net10.0 -- --demo-trust --target Peripheral1 --command configure --sensor Temperature --trigger-ms 2000 --consent --prove-refusal
# Transfer generated, nonsecret demonstration bytes. Acceptance is not installation.
dotnet run --no-build --project samples\MachineTool\MachineToolClient -f net10.0 -- --demo-trust --target Peripheral1 --command firmware --transfer-bytes 32 --consent
Use --help for calibration, explicit UTC time, selected record deletion,
licence transfer and explicit abort. Local timeout/cancellation never sends
AbortOperation or retries an uncertain write.
Each peripheral accepts at most one simulated configuration, calibration,
time setting and transfer of each kind; later requests are refused. A refused
configuration retains the previously accepted trigger/delta.
The separately selected server --simulate-job Machine1 supplies explicit
execution/part observations after StoreAndStart. Job acceptance alone never
means a machine executed anything.
Lifetimes and bounds
Server windows are 1-600 seconds. Client work has a 90-second deadline;
observation is 0-20 seconds and 1-100 notifications. Discovery, sensors, files,
record reports and transfer bytes have explicit ceilings. Oversize data fails,
not silently truncated success. --freeze-measurements demonstrates real stale
quality on advanced wireless observations.
--cancel-after-ms exercises bounded cancellation. Exit codes are 0 completed,
1 error/refusal, and 2 cancelled. Natural server shutdown joins acquisition,
drains runtimes, releases providers and deletes only its generated temporary
read-only program folders. PKI remains available for administration.
Clients close call-owned subscriptions/files and their managed session.
Frameworks and NativeAOT
Both projects support net48, net8.0, net9.0 and net10.0. NativeAOT is selected only on the application projects for net10.0:
dotnet publish samples\MachineTool\MachineToolServer -c Release -f net10.0 -r win-x64 --self-contained true
dotnet publish samples\MachineTool\MachineToolClient -c Release -f net10.0 -r win-x64 --self-contained true
Run the published executables with the same CLI arguments; publishing alone does not prove native behavior. See the developer guide for provider contracts and CompanionSuite for all families on one DI/Machinery owner.