ContinueLogout was unreachable and, once reached, produced no response.
Two independent defects, both of which had to be fixed for the endpoint
to work at all.
Authorization. The endpoint declared neither a permission nor
AllowAnonymous, so it inherited the FastEndpoints default and required an
authenticated caller. It cannot ever satisfy that: the broker revokes the
session before issuing the continuation handle, and the endpoint is
reached by a top-level browser navigation, which sends no Authorization
header -- the only transport Elsa authentication uses. Every other broker
endpoint the browser is navigated to is already AllowAnonymous for the
same reason. The single-use, hashed route handle carries the authority.
Response. The handler wrote to HttpContext.Response directly rather than
through the Send API, so the response never started and the FastEndpoints
auto-response overwrote the status with 204. Both branches were affected:
the redirect to the provider's end-session endpoint and the 400 for an
unknown handle were each discarded, so a caller received 204 No Content
either way. Now mirrors CompleteLogout, using Send.RedirectAsync and
BrokerEndpointSupport.SendErrorAsync.
Logout, in the same file, also relies on an inherited default, but there
the default is correct: it reads the external session id from the
principal, so it needs an identity and no permission. Left as-is with a
comment; an explicit authenticated-only declaration arrives with the
authorization model work.
Adds LogoutAuthorizationTests, which builds a host with authorization
enforced and no principal injected -- the existing broker fixture injects
one and disables endpoint security, so it could not catch either defect.
Verified failing before the change (401, then 204) and passing after.
Fixes#7976
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix: stop two silent serialization and test-isolation traps
Two follow-ups from #7957.
ExternalAuthentication tests: the same process-global
EndpointSecurityOptions.SecurityIsEnabled race the shells API tests had,
across the six classes in that assembly that build an endpoint host —
five setting it to false and IdentityLinkAuthorizationTests to true.
Unlike the shells case these all call UseAuthorization(), so it does not
surface as a missing-middleware error: anonymous endpoints answer
401/403, and the authorization test's endpoints come back AllowAnonymous
and stop enforcing what it asserts. A module initializer cannot fix it
since the assembly genuinely needs both values, so the six now share one
collection with DisableParallelization. They are also the only six that
build a host, so nothing else can observe a leaked value.
Unaliased payloads: a payload whose type has no registered serialization
alias is written without a _type discriminator and read back as an
ExpandoObject whose keys carry the state serializer's camel-case naming
policy, so a consumer that published Status finds status. The
degradation is deliberate — the alias registry is an allow-list that
keeps arbitrary CLR type names out of deserialization — but it was
silent. It is now reported once per type, naming the type and both
lossless alternatives, and PublishEvent.Payload documents them. Measured
across the integration suite, only genuine user payload types reach this
path, so the warning does not fire for Elsa's own types.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix: check the log level before claiming the once-per-type warning slot
WarnAboutUnaliasedType claimed a type's single report via TryAdd before
LogWarning applied its level filter, so a type first serialized while
Warning was disabled spent its slot on a call that logged nothing and
then stayed silent forever, including after the level was raised at
runtime. Check IsEnabled first, so the slot is only consumed by a report
that is actually emitted.
The regression test needs the capture to be the only logging provider:
IsEnabled on the composite logger is an OR across providers, so the test
builder's own xunit provider would otherwise keep Warning enabled
regardless of what the test asked for.
Reported by Greptile on #7969.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Use the same structural and secret-binding assessment for management, discovery, and initiation so incomplete overrides are never advertised as available sign-in methods.
Introduce a new test `ValidateRequiresCompleteConfigurationAndReturnsMissingSecretDetails` to verify that a connection requires a complete configuration, including handling missing secret details. Adjust configuration to enforce `RequiresClientSecret`.
