[ISSUE #15510] Reject invalid credential before anonymous fallback

[jay666mnj]

What is the purpose of the change

Fix #15510.

When anonymous AI access is enabled, requests with an explicitly supplied invalid credential, such as Authorization: Bearer invalid-token, should not silently fall back to anonymous access.

This change keeps anonymous access available for requests without credentials, but rejects requests that provide invalid explicit credentials.

Brief changelog

• Prevent anonymous fallback when the request contains explicit credentials.
• Treat Authorization, accessToken, username, or password as explicit credentials.
• Add a unit test to verify invalid Bearer token requests are rejected instead of being treated as anonymous access.

Verifying this change

Run:

.\mvnw.cmd --% -pl plugin-default-impl/nacos-default-auth-plugin -am -Dtest=NacosAuthPluginServiceTest#testValidateIdentityAnonymousAllowedAndDenied -Dsurefire.failIfNoSpecifiedTests=false -DskipITs test

git diff --check

Result:

• Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
• Reactor BUILD SUCCESS
• git diff --check passed

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
• Run mvn -B clean package apache-rat:check spotbugs:check -DskipTests to make sure basic checks pass. Run mvn clean install to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test to make sure integration-test pass.

[github-actions]

Thanks for your this PR. 🙏
Please check again for your PR changes whether contains any usage/api/configuration change such as Add new API , Add new configuration, Change default value of configuration.
If so, please add or update documents(markdown type) in docs/next/ for repository nacos-group/nacos-group.github.io

---

感谢您提交的PR。 🙏
请再次查看您的PR内容，确认是否包含任何使用方式/API/配置参数的变更，如：新增API、新增配置参数、修改默认配置等操作。
如果是，请确保在提交之前，在仓库nacos-group/nacos-group.github.io中的docs/next/目录下添加或更新文档（markdown格式）。

[saynoword]

Thanks for fixing the invalid-credential anonymous fallback. The general direction looks correct, but I think the following issues should be addressed before merging:

1. hasExplicitCredential currently checks whether credential values are non-blank rather than whether credentials were explicitly supplied. HttpIdentityContextBuilder reads headers first and request parameters afterward, so a request parameter such as ?Authorization= can overwrite an invalid Authorization header with an empty string. The subsequent authentication failure may therefore still fall back to anonymous access. Please detect credential presence instead, for example with getParameter(key) != null, and cover blank credentials and header/parameter collisions in tests.

2. The new unit test only verifies that the auth plugin returns an AuthResult with code 401. At the HTTP layer, AbstractWebAuthFilter converts any failed identity result into an AccessException and returns HTTP 403. Issue Invalid Bearer token silently falls back to anonymous access #15510 expects 401, while the current response/error spec defines AccessException as 403. Please clarify the intended HTTP contract and add an API-level integration test that verifies the actual status code and response body.

3. This changes spec-covered authentication behavior and the observable HTTP contract. Per the repository contribution rules, please update the English and Chinese default-auth specs, add the corresponding test/openapi-test scenario, and update API_TEST_COVERAGE.md and the relevant scenario matrix. If the standalone IT environment cannot exercise anonymous access, please document the uncovered path and cover the applicable boundary/error behavior.

[jay666mnj]

Thanks for fixing the invalid-credential anonymous fallback. The general direction looks correct, but I think the following issues should be addressed before merging:

1. hasExplicitCredential currently checks whether credential values are non-blank rather than whether credentials were explicitly supplied. HttpIdentityContextBuilder reads headers first and request parameters afterward, so a request parameter such as ?Authorization= can overwrite an invalid Authorization header with an empty string. The subsequent authentication failure may therefore still fall back to anonymous access. Please detect credential presence instead, for example with getParameter(key) != null, and cover blank credentials and header/parameter collisions in tests.
2. The new unit test only verifies that the auth plugin returns an AuthResult with code 401. At the HTTP layer, AbstractWebAuthFilter converts any failed identity result into an AccessException and returns HTTP 403. Issue Invalid Bearer token silently falls back to anonymous access #15510 expects 401, while the current response/error spec defines AccessException as 403. Please clarify the intended HTTP contract and add an API-level integration test that verifies the actual status code and response body.
3. This changes spec-covered authentication behavior and the observable HTTP contract. Per the repository contribution rules, please update the English and Chinese default-auth specs, add the corresponding test/openapi-test scenario, and update API_TEST_COVERAGE.md and the relevant scenario matrix. If the standalone IT environment cannot exercise anonymous access, please document the uncovered path and cover the applicable boundary/error behavior.

I updated the PR to address the review points:

1. Explicit credentials are now detected by key presence instead of non-blank values. Blank Authorization, accessToken, username, or password values are treated as explicit credentials and no longer fall back to anonymous access.
2. HttpIdentityContextBuilder now avoids letting a blank request parameter overwrite an existing header credential.
3. Added HTTP filter coverage for the actual external contract: auth plugin identity failure is returned by the HTTP layer as HTTP 403 with ACCESS_DENIED, while preserving the plugin failure detail in the response.
4. Updated the English and Chinese default-auth specs and the OpenAPI coverage/scenario docs. The standalone OpenAPI IT does not mutate anonymous access because it would affect shared server state, so the anonymous credential boundary and HTTP error mapping are covered by auth/core unit tests.

Verified with the targeted unit tests for IdentityContext, HttpIdentityContextBuilder, NacosAuthPluginService, and AuthFilter.

[saynoword]

Thanks for fixing the invalid-credential anonymous fallback. The general direction looks correct, but I think the following issues should be addressed before merging:

1. hasExplicitCredential currently checks whether credential values are non-blank rather than whether credentials were explicitly supplied. HttpIdentityContextBuilder reads headers first and request parameters afterward, so a request parameter such as ?Authorization= can overwrite an invalid Authorization header with an empty string. The subsequent authentication failure may therefore still fall back to anonymous access. Please detect credential presence instead, for example with getParameter(key) != null, and cover blank credentials and header/parameter collisions in tests.
2. The new unit test only verifies that the auth plugin returns an AuthResult with code 401. At the HTTP layer, AbstractWebAuthFilter converts any failed identity result into an AccessException and returns HTTP 403. Issue Invalid Bearer token silently falls back to anonymous access #15510 expects 401, while the current response/error spec defines AccessException as 403. Please clarify the intended HTTP contract and add an API-level integration test that verifies the actual status code and response body.
3. This changes spec-covered authentication behavior and the observable HTTP contract. Per the repository contribution rules, please update the English and Chinese default-auth specs, add the corresponding test/openapi-test scenario, and update API_TEST_COVERAGE.md and the relevant scenario matrix. If the standalone IT environment cannot exercise anonymous access, please document the uncovered path and cover the applicable boundary/error behavior.

I updated the PR to address the review points:

1. Explicit credentials are now detected by key presence instead of non-blank values. Blank Authorization, accessToken, username, or password values are treated as explicit credentials and no longer fall back to anonymous access.
2. HttpIdentityContextBuilder now avoids letting a blank request parameter overwrite an existing header credential.
3. Added HTTP filter coverage for the actual external contract: auth plugin identity failure is returned by the HTTP layer as HTTP 403 with ACCESS_DENIED, while preserving the plugin failure detail in the response.
4. Updated the English and Chinese default-auth specs and the OpenAPI coverage/scenario docs. The standalone OpenAPI IT does not mutate anonymous access because it would affect shared server state, so the anonymous credential boundary and HTTP error mapping are covered by auth/core unit tests.

Verified with the targeted unit tests for IdentityContext, HttpIdentityContextBuilder, NacosAuthPluginService, and AuthFilter.

After reviewing the updated implementation, I think the IdentityContext.containsParameter addition is reasonable, but the HttpIdentityContextBuilder precedence change is unnecessary for this fix and should be removed.

containsParameter is an additive, side-effect-free query method on a concrete class. It does not change existing request parsing or authentication behavior unless explicitly called, and it remains source- and binary-compatible with existing auth plugins.

For the anonymous fallback fix, checking key presence is sufficient. Even if a blank request parameter overwrites an Authorization header value, the key still exists in IdentityContext, so containsParameter("Authorization") remains true and anonymous fallback will be rejected.

Therefore, I suggest:

1. Keep IdentityContext.containsParameter.
2. Keep hasExplicitCredential in AbstractNacosAuthPluginService.
3. Keep the invalid Bearer, blank credential, and HTTP 403 tests.
4. Revert the HttpIdentityContextBuilder header/parameter precedence change and its related test.

This keeps the change scoped to resources that explicitly enable anonymous access. In practice, the behavioral impact remains limited to the four Skill/AgentSpec anonymous endpoints, without changing credential precedence for all HTTP APIs, OIDC, or third-party auth plugins.

[jay666mnj]

Thanks for fixing the invalid-credential anonymous fallback. The general direction looks correct, but I think the following issues should be addressed before merging:

1. hasExplicitCredential currently checks whether credential values are non-blank rather than whether credentials were explicitly supplied. HttpIdentityContextBuilder reads headers first and request parameters afterward, so a request parameter such as ?Authorization= can overwrite an invalid Authorization header with an empty string. The subsequent authentication failure may therefore still fall back to anonymous access. Please detect credential presence instead, for example with getParameter(key) != null, and cover blank credentials and header/parameter collisions in tests.
2. The new unit test only verifies that the auth plugin returns an AuthResult with code 401. At the HTTP layer, AbstractWebAuthFilter converts any failed identity result into an AccessException and returns HTTP 403. Issue Invalid Bearer token silently falls back to anonymous access #15510 expects 401, while the current response/error spec defines AccessException as 403. Please clarify the intended HTTP contract and add an API-level integration test that verifies the actual status code and response body.
3. This changes spec-covered authentication behavior and the observable HTTP contract. Per the repository contribution rules, please update the English and Chinese default-auth specs, add the corresponding test/openapi-test scenario, and update API_TEST_COVERAGE.md and the relevant scenario matrix. If the standalone IT environment cannot exercise anonymous access, please document the uncovered path and cover the applicable boundary/error behavior.

I updated the PR to address the review points:

1. Explicit credentials are now detected by key presence instead of non-blank values. Blank Authorization, accessToken, username, or password values are treated as explicit credentials and no longer fall back to anonymous access.
2. HttpIdentityContextBuilder now avoids letting a blank request parameter overwrite an existing header credential.
3. Added HTTP filter coverage for the actual external contract: auth plugin identity failure is returned by the HTTP layer as HTTP 403 with ACCESS_DENIED, while preserving the plugin failure detail in the response.
4. Updated the English and Chinese default-auth specs and the OpenAPI coverage/scenario docs. The standalone OpenAPI IT does not mutate anonymous access because it would affect shared server state, so the anonymous credential boundary and HTTP error mapping are covered by auth/core unit tests.

Verified with the targeted unit tests for IdentityContext, HttpIdentityContextBuilder, NacosAuthPluginService, and AuthFilter.

After reviewing the updated implementation, I think the IdentityContext.containsParameter addition is reasonable, but the HttpIdentityContextBuilder precedence change is unnecessary for this fix and should be removed.

containsParameter is an additive, side-effect-free query method on a concrete class. It does not change existing request parsing or authentication behavior unless explicitly called, and it remains source- and binary-compatible with existing auth plugins.

For the anonymous fallback fix, checking key presence is sufficient. Even if a blank request parameter overwrites an Authorization header value, the key still exists in IdentityContext, so containsParameter("Authorization") remains true and anonymous fallback will be rejected.

Therefore, I suggest:

1. Keep IdentityContext.containsParameter.
2. Keep hasExplicitCredential in AbstractNacosAuthPluginService.
3. Keep the invalid Bearer, blank credential, and HTTP 403 tests.
4. Revert the HttpIdentityContextBuilder header/parameter precedence change and its related test.

This keeps the change scoped to resources that explicitly enable anonymous access. In practice, the behavioral impact remains limited to the four Skill/AgentSpec anonymous endpoints, without changing credential precedence for all HTTP APIs, OIDC, or third-party auth plugins.

Thanks for the review. I updated the PR to narrow the change scope as suggested.

• Kept IdentityContext.containsParameter.
• Kept hasExplicitCredential in AbstractNacosAuthPluginService.
• Kept the invalid Bearer, blank credential, and HTTP 403 coverage.
• Reverted the HttpIdentityContextBuilder header/parameter precedence change and removed its related test.
• Resolved the conflicts with the latest develop and updated the OpenAPI coverage docs accordingly.