freesinger commented on issue #11089: URL: https://github.com/apache/gravitino/issues/11089#issuecomment-4459032641
Thanks for pointing this out. The reason was not just to align with IRC. My original concern was that in auxiliary mode Lance REST is already running inside the Gravitino server process, so calling Gravitino through GravitinoClient means the request has to go out through HTTP and enter the same server again. That adds an extra loopback path and also makes auth semantics less straightforward, because the outer Lance request has already gone through server filters while the inner GravitinoClient request needs another identity/auth context. That said, I agree that directly depending on internal dispatchers weakens the previous client/server layer separation, and the coupling may not be worth it if we can handle the identity propagation cleanly through the client path. One concern with plain header forwarding is that it can easily become ad-hoc and ambiguous: we need to define exactly which auth context is propagated, avoid forwarding unrelated or spoofable headers, and keep audit semantics clear. Maybe a better approach is to keep Lance REST using GravitinoClient, but introduce a controlled request-context propagation layer for auxiliary services, where the client forwards only an allowlisted auth/request context to the Gravitino server and lets the server side perform centralized authorization. -- 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]
