Fix BasicAuth default handler fail-open behavior

[CypherPotato]

Motivation

• The parameterless BasicAuthenticateRequestHandler constructor previously wired a validator that returned null, and null is interpreted as successful authentication, causing a fail-open where any syntactically valid Basic auth blob granted access.
• This behavior is a security risk for callers that construct the handler without providing a validator or that forget to override OnValidating, so the default should be deny-by-default.

Description

• Change the parameterless constructor to use a default-deny delegate that returns 401 Unauthorized instead of returning null, making new BasicAuthenticateRequestHandler() fail-closed.
• Add a small private static helper CreateDefaultUnauthorizedResponse to produce the 401 response used by the default delegate.
• Preserve existing extensibility by keeping the delegate-based constructors and the OnValidating virtual method semantics unchanged.

Testing

• Attempted dotnet build extensions/Sisk.BasicAuth/Sisk.BasicAuth.csproj -c Debug -f net6.0 /p:RestoreIgnoreFailedSources=true, which failed in this environment due to missing restored assets for net6.0.
• Ran dotnet build extensions/Sisk.BasicAuth/Sisk.BasicAuth.csproj -c Debug /p:RestoreIgnoreFailedSources=true, which completed successfully and produced the extension assembly, indicating the change compiles.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 90bba36fa6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Honor configured Realm in default validator response

The new parameterless constructor wires validateDefault to always call CreateDefaultUnauthorizedResponse(DefaultRealm), which hard-codes the challenge realm. If a caller constructs new BasicAuthenticateRequestHandler(), then sets Realm (e.g., for a custom protection scope), requests with an Authorization header now return 401 with the default realm instead of the configured one, while other unauthorized paths still use Realm; this creates inconsistent auth challenges and breaks runtime realm customization.

Useful? React with 👍 / 👎.