Skip to content

branch-4.1: [fix](auth) add auth check for manager node and query qerror REST APIs#65080

Open
CalvinKirs wants to merge 3 commits into
branch-4.1from
4.1-65042-59708
Open

branch-4.1: [fix](auth) add auth check for manager node and query qerror REST APIs#65080
CalvinKirs wants to merge 3 commits into
branch-4.1from
4.1-65042-59708

Conversation

@CalvinKirs

Copy link
Copy Markdown
Member

cherry-pick #65042
cherry-pick #59708

heguanhui and others added 3 commits July 1, 2026 14:42
…use of PathVariable annotation without value declaration (#59708)
… query qerror REST APIs

The node management endpoints (POST /rest/v2/manager/node/{action}/{fe,be,broker})
allowed adding or dropping cluster nodes without any authentication or
authorization. Add executeCheckPassword + checkAdminAuth so they require an
authenticated ADMIN user, consistent with set_config/fe and set_config/be.

GET /rest/v2/manager/query/qerror/{id} (getStats) had neither authentication
nor authorization: its signature took no request/response and the global
AuthInterceptor only covers /rest/v1/**, so it was reachable anonymously even
with enable_all_http_auth=true. Add executeCheckPassword and
checkAuthByUserAndQueryId, matching the /profile and /trace_id endpoints, so a
non-admin can only read their own query stats.

Add a p0 regression test covering both gaps.
The admin-positive assertions used ADD with 127.0.0.1 addresses, which on a
real (distributed) cluster would not match an existing node and would actually
register a phantom FE observer / BE into the editlog with no cleanup, polluting
cluster state and risking later tests.

Switch the positive path to DROP on RFC 5737 TEST-NET addresses (192.0.2.x),
which can never match a real node: it reaches the operation, returns a harmless
'does not exist' error, proves the ADMIN check passed, and mutates nothing. The
negative (non-admin) cases keep ADD since the auth check rejects them before the
node operation runs.
@CalvinKirs CalvinKirs requested a review from yiguolei as a code owner July 1, 2026 06:43
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@CalvinKirs

Copy link
Copy Markdown
Member Author

run buildall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants