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>
ae146a1765