bharos commented on issue #11130: URL: https://github.com/apache/gravitino/issues/11130#issuecomment-4481617638
Thanks for filing this — the current behavior (returning 403 for non-existent resources) is **intentional** as a security measure to prevent resource enumeration. We have explicit test coverage for this: - [`TestGravitinoInterceptionService.testMetalakeNotExist()`](https://github.com/apache/gravitino/blob/main/server/src/test/java/org/apache/gravitino/server/web/filter/TestGravitinoInterceptionService.java#L151) — verifies 403 is returned when a metalake doesn't exist - [`JobAuthorizationIT.testJobOperationsWithNonExistentMetalake()`](https://github.com/apache/gravitino/blob/main/clients/client-java/src/test/java/org/apache/gravitino/client/integration/test/authorization/JobAuthorizationIT.java#L307) — explicitly asserts `ForbiddenException` for all operations against non-existent metalakes - The interceptor logic in [`GravitinoInterceptionService.java` L167](https://github.com/apache/gravitino/blob/main/server/src/main/java/org/apache/gravitino/server/web/filter/GravitinoInterceptionService.java#L167) catches `NoSuchMetalakeException` and intentionally returns 403 That said, I can see how this breaks Flink Calcite's speculative identifier resolution pattern. The argument that returning 403 for a non-existent resource leaks no less information than 404 (since there's nothing to protect) is reasonable. cc @roryqi for your opinion on changing this behavior? Specifically: should the auth interceptor let the request pass through (returning 404 naturally) when the target resource doesn't exist? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
