Summary
A route protected only by httpBasic() returns a 401 with:
even though the route accepts HTTP Basic credentials, not a bearer token.
This prevents HTTP clients, proxies, and application UIs from discovering the authentication scheme from the standard challenge, and a direct browser navigation cannot present its normal Basic authentication prompt.
Reproduction
Using eve@0.24.6:
import { httpBasic, routeAuth } from "eve/channels/auth";
const response = await routeAuth(
new Request("https://agent.example/eve/v1/session"),
httpBasic({ username: "eve", password: "eve" }),
);
console.log({
status: response.status,
challenge: response.headers.get("www-authenticate"),
body: await response.json(),
});Actual result:
{
"status": 401,
"challenge": "Bearer",
"body": {
"code": "unauthorized",
"error": "Authorization is required for this route.",
"ok": false
}
}The same behavior is observable through an eveChannel configured with only:
eveChannel({
auth: [httpBasic({ username: "eve", password: "eve" })],
});Expected behavior
The failure should advertise the scheme the route actually accepts, for example:
WWW-Authenticate: Basic realm="agent", charset="UTF-8"
For an auth array with multiple supported schemes, the response should ideally advertise all applicable challenges. At minimum, a Bearer challenge should not be emitted when no bearer-compatible auth strategy is configured.
Current cause
httpBasic() returns null when verification fails. After every auth function returns null, routeAuth() creates the generic unauthorized response with a hard-coded Bearer challenge:
return createUnauthorizedResponse({
challenges: [{ scheme: "Bearer" }],
});Possible direction
One option is to let auth strategies declare their challenge metadata and have routeAuth() collect the challenges for strategies that did not authenticate the request. That would preserve fallback auth arrays without making a failed httpBasic() terminate the auth walk.
It would also be useful to cover:
httpBasic() alone advertises Basic;- bearer/OIDC strategies advertise Bearer;
- mixed Basic + Bearer arrays advertise both;
- successful authentication includes no challenge;
- custom
UnauthenticatedError responses continue to take precedence.
Version
Observed with eve@0.24.6.
Summary
A route protected only by
httpBasic()returns a401with:WWW-Authenticate: Bearereven though the route accepts HTTP Basic credentials, not a bearer token.
This prevents HTTP clients, proxies, and application UIs from discovering the authentication scheme from the standard challenge, and a direct browser navigation cannot present its normal Basic authentication prompt.
Reproduction
Using
eve@0.24.6:Actual result:
{ "status": 401, "challenge": "Bearer", "body": { "code": "unauthorized", "error": "Authorization is required for this route.", "ok": false } }The same behavior is observable through an
eveChannelconfigured with only:Expected behavior
The failure should advertise the scheme the route actually accepts, for example:
WWW-Authenticate: Basic realm="agent", charset="UTF-8"For an auth array with multiple supported schemes, the response should ideally advertise all applicable challenges. At minimum, a Bearer challenge should not be emitted when no bearer-compatible auth strategy is configured.
Current cause
httpBasic()returnsnullwhen verification fails. After every auth function returnsnull,routeAuth()creates the generic unauthorized response with a hard-coded Bearer challenge:Possible direction
One option is to let auth strategies declare their challenge metadata and have
routeAuth()collect the challenges for strategies that did not authenticate the request. That would preserve fallback auth arrays without making a failedhttpBasic()terminate the auth walk.It would also be useful to cover:
httpBasic()alone advertises Basic;UnauthenticatedErrorresponses continue to take precedence.Version
Observed with
eve@0.24.6.