[
https://issues.apache.org/jira/browse/YARN-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006542#comment-14006542
]
Zhijie Shen commented on YARN-2049:
-----------------------------------
Thanks for review, Vinod and Varun! Please see the response bellow:
bq. 1. In the function managementOperation, should there be a null check for
token?
There're following code before processing each dtOp:
{code}
if (dtOp.requiresKerberosCredentials() && token == null) {
response.sendError(HttpServletResponse.SC_UNAUTHORIZED,
MessageFormat.format(
"Operation [{0}] requires SPNEGO authentication established",
dtOp));
requestContinues = false;
{code}
Get and renew both require kerberos credentials, such that if token == null,
the code will fall into this part. Cancel didn't require credentials before
refer to HttpFS's code. However, I think we should enforce kerberos credentials
for cancel as well. After that, the NPE risk is gone.
bq. In the function managementOperation, you call secretManager.cancelToken(dt,
UserGroupInformation.getCurrentUser().getUserName()) - should you use
getCurrentuser().getUserName? or ownerUGI.getUserName()?
Good catch, we should use token.getUserName here as well.
bq. TimelineKerberosAuthenticator
Some errors may cause TimelineAuthenticator not getting the correct response.
If the status code is not 200, the json content may contain the exception
information from the server, we can use the information recover exception
object. This is inspired by HttpFSUtils.validateResponse, but I changed to use
Jackson to parse the json content here.
bq. TimelineAuthenticationFilter
In the configuration we can simply set the authentication type to "kerberos",
but in the timeline sever, we want to replace it with the class name of the
customized authentication service. Otherwise, the standard authentication
handler will be used instead. I added the code comments there.
bq. TimelineKerberosAuthenticationHandler
bq. TimelineDelegationTokenSecretManagerService.
Yeah, we need to look into how to reuse the existing code, but how about
postpone it later? I'm going to file a separate Jira for code refactoring.
bq. TestDistributedShell change is unnecessary
Removed.
bq. TimelineDelegationTokenSelector: Wrap the debug logging in debugEnabled
checks.
Added the debugEnabled checks.
bq. ApplicationHistoryServer.java
Actually it will not override the other initializers. Instead, I just append a
TimelineAuthenticationFilterInitializer. Anyway, I enhance the condition here:
not only the security should be enabled, but also "kerberos" authentication is
desired.
bq. TimelineKerberosAuthenticationHandler
Done.
bq. TimelineKerberosAuthenticator.
Good suggestion. I split the code accordingly.
bq. TimelineAuthenticationFilterInitializer
AuthenticationFilterInitializer has a single method to do everything, and the
prefix is a static variable, which makes me a bit difficult to override part of
code without changing AuthenticationFilterInitializer. One another issue is
that AuthenticationFilterInitializer requires user to supply a secret file,
which is not actually required by AuthenticationFilter (HADOOP-10600).
> Delegation token stuff for the timeline sever
> ---------------------------------------------
>
> Key: YARN-2049
> URL: https://issues.apache.org/jira/browse/YARN-2049
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Zhijie Shen
> Assignee: Zhijie Shen
> Attachments: YARN-2049.1.patch, YARN-2049.2.patch, YARN-2049.3.patch,
> YARN-2049.4.patch, YARN-2049.5.patch, YARN-2049.6.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
