[ 
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822983#comment-15822983
 ] 

Josh Elser commented on CALCITE-1539:
-------------------------------------

Thanks for the patch, [~Wancy]!

bq.  Looks ok to me. Given the API change, this is probably only suitable for a 
major release. I am not clear about Calcite's Deprecation policy.

We don't have a well-defined policy now, but old methods such as this need to 
be preserved.

{code}
-  public <T> T doAsRemoteUser(String remoteUserName, String remoteAddress, 
final Callable<T> action) throws Exception {
+  public <T> T doAsRemoteUser(String remoteUserName, String doAsUser, String 
remoteAddress, final Callable<T> action) throws Exception {
{code}

What is the use-case where the remote user is different than the user we would 
execute the query as? I'm not seeing a reason to have separate notions of 
"remote" and "doAs" users. Might it be better to define different ways that the 
remote "user" can be extracted (via the HTTP request, a property in the query 
string)?

{code}
-            jsonResponse = serverConfig.doAsRemoteUser(request.getRemoteUser(),
+            jsonResponse = 
serverConfig.doAsRemoteUser(request.getRemoteUser(), request.getQueryString(),
{code}

Passing the entire query string is not correct. If anything, it would be one 
field in the query string.

Two other things: should the JDBC driver have a way to set this user? Also, 
this patch needs some tests (which will help show the end-to-end usage).

> Enable proxy access to Avatica server for third party on behalf of end users
> ----------------------------------------------------------------------------
>
>                 Key: CALCITE-1539
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1539
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Jerry He
>            Assignee: Josh Elser
>         Attachments: 
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the 
> end user comes in via a third party impersonation.  For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server 
> HIVE-5155



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to