[
https://issues.apache.org/jira/browse/KUDU-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriella Lotz updated KUDU-3639:
---------------------------------
Description:
The CatalogManager::\{DeleteTableRpc, CreateTable, AlterTableRpc} functions
currently rely on rpc::RpcContext to extract the username of the requestor for
authorization. However, in the REST catalog API implementation, RpcContext is
not used, and only the username is directly available.
To support REST API functionality, new functions are required that replace
RpcContext with an explicitly provided username while maintaining the same core
logic for table operations.
Requirements:
* Create new functions:
** CatalogManager::DeleteTableWithUser
** CatalogManager::AlterTableWithUser
** CatalogManager::CreateTableWithUser
* These functions should:
** Accept a username parameter instead of rpc::RpcContext.
** Implement the same authorization, logging, and HMS integration logic as
their corresponding RPC versions (DeleteTableRpc, AlterTableRpc, and
CreateTable).
** Refactor shared logic between the existing RPC functions and the new
\{Delete/Alter/Create}TableWithUser functions into reusable helper functions to
minimize code duplication.
was:
The CatalogManager::\{DeleteTableRpc, CreateTable, AlterTableRpc} functions
currently rely on rpc::RpcContext to extract the username of the requestor for
authorization. However, in the REST catalog API implementation, RpcContext is
not used, and only the username is directly available.
To support REST API functionality, new functions are required that replace
RpcContext with an explicitly provided username while maintaining the same core
logic for table operations.
{code:java}
Status CatalogManager::DeleteTableRpc(const DeleteTableRequestPB& req,
DeleteTableResponsePB* resp,
rpc::RpcContext* rpc) { LOG(INFO) << Substitute("Servicing
DeleteTable request from $0:\n$1",
RequestorString(rpc), SecureShortDebugString(req));
leader_lock_.AssertAcquiredForReading();
optional<string> user; if (rpc) {
user.emplace(rpc->remote_user().username()); }{code}
Requirements:
* Create new functions:
** CatalogManager::DeleteTableWithUser
** CatalogManager::AlterTableWithUser
** CatalogManager::CreateTableWithUser
* These functions should:
** Accept a username parameter instead of rpc::RpcContext.
** Implement the same authorization, logging, and HMS integration logic as
their corresponding RPC versions (DeleteTableRpc, AlterTableRpc, and
CreateTable).
** Refactor shared logic between the existing RPC functions and the new
\{Delete/Alter/Create}TableWithUser functions into reusable helper functions to
minimize code duplication.
> Implement {Delete/Alter/Create}Table Functions Without RpcContext
> -----------------------------------------------------------------
>
> Key: KUDU-3639
> URL: https://issues.apache.org/jira/browse/KUDU-3639
> Project: Kudu
> Issue Type: New Feature
> Reporter: Gabriella Lotz
> Assignee: Gabriella Lotz
> Priority: Major
>
> The CatalogManager::\{DeleteTableRpc, CreateTable, AlterTableRpc} functions
> currently rely on rpc::RpcContext to extract the username of the requestor
> for authorization. However, in the REST catalog API implementation,
> RpcContext is not used, and only the username is directly available.
> To support REST API functionality, new functions are required that replace
> RpcContext with an explicitly provided username while maintaining the same
> core logic for table operations.
> Requirements:
> * Create new functions:
> ** CatalogManager::DeleteTableWithUser
> ** CatalogManager::AlterTableWithUser
> ** CatalogManager::CreateTableWithUser
> * These functions should:
> ** Accept a username parameter instead of rpc::RpcContext.
> ** Implement the same authorization, logging, and HMS integration logic as
> their corresponding RPC versions (DeleteTableRpc, AlterTableRpc, and
> CreateTable).
> ** Refactor shared logic between the existing RPC functions and the new
> \{Delete/Alter/Create}TableWithUser functions into reusable helper functions
> to minimize code duplication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
