HTTP Basic Auth filter

[zhaohuabing]

The implementation for HTTP Basic Auth filter.

Description: HTTP Basic Authn is a frequently requested feature from users, I'd like to have Envoy to support it.

Related issue: #15365

Sponsor: wbpcode

Risk Level: low
Testing: Yes
Docs Changes: Yes
Release Notes: Yes
Platform Specific Features: No
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #30079 was opened by zhaohuabing.

see: more, trace.

[wbpcode]

Sounds a reasonable contribution, thanks. But I think at lease one maintainer sponsor and two reviewers for this new core extension.

All extensions must be sponsored by an existing maintainer. Sponsorship means that the maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor extensions if they are going to write them, shepherd them, and maintain them.

Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other contributors can count towards this number. The initial reviewers will be codified in the CODEOWNERS file for long term maintenance. These reviewers can be swapped out as needed.

See https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md for more detail.

If you are willing, I can help to review or even sponsor it (this extension should be simple and won't take too much bandwidth), but we still need another reviewer to ensure the quality of extension.

Or you can add this extension as contrib extension. contrib extension have a relatively loose requirement.

[mattklein123]

Seems OK to me to add if @wbpcode is willing to review.

[zhaohuabing]

@wbpcode Since we agreed on the API, I converted this PR to draft and proceed with implementation.

[wbpcode]

Both is OK for this function (because this only be called once when configuration is loaded), although string view still be better to reduce unnecessary sub-string copy/creation.

I changed it back to std::string because the compiler was not happy about this line:

users->emplace(name, User{std::string(name), std::string(hash)});

SGTM, we can optimize it in the future anyway, if we have free time. Just merge main and add a release note. :)

[wbpcode]

LGTM. Thanks.

Hi, cc @mattklein123 could you also give a quick check in case I am missing something?

[cpakulski]

Few typos.
Should integration test be added to make sure that it works e-2-e?

[wbpcode]

Should integration test be added to make sure that it works e-2-e?

SGTM. But I have no strong opinion on this because this extension is pretty simple.

[zhaohuabing]

Should integration test be added to make sure that it works e-2-e?

SGTM. But I have no strong opinion on this because this extension is pretty simple.

Should I add an e-2-e test? Looks like there are no e-2-e tests for HTTP filters in the test/integration directory, or I looked into the wrong place?

[wbpcode]

Integration tests are placed in sub directory of filter itself.

You can check test/extensions/filters/http/fault/fault_filter_integration_test.cc as a example to see how to write a integration test of http filter.

[zhaohuabing]

@wbpcode @cpakulski Integration test has been added. PTAL.

[zhaohuabing]

/retest

[wbpcode]

LGTM. Thanks.

[mattklein123]

Nice!