[
https://issues.apache.org/jira/browse/KUDU-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021871#comment-16021871
]
Alexey Serbin commented on KUDU-1925:
-------------------------------------
Since {{3db551f7b31def26c0fa04184843d3dfa6161d9a}}, the C++ client
automatically tries to re-acquire authn token if receiving
FATAL_INVALID_AUTHENTICATION_TOKEN error code from the server. If the token
cannot be re-acquired, after trying in vain the client will timeout on one of
its token re-acquire retry calls.
Adding more information on specific error would be nice, but all the 'regular'
scenarios of {{TokenVerifier::VerifyTokenSignature}} are already covered by
{{3db551f7b31def26c0fa04184843d3dfa6161d9a}} and
{{d4cffa503ae8d913bf3834bcc92f75f80d1f640f}} (token expiration and using
unknown to the token verifier signing key, correspondingly).
The only non-covered part or 'regular' is handling the case of
{{security::VerificationResult::INCOMPATIBLE_FEATURE}} token verification
result. We can do it a little bit later in 1.5.
> Server should propagate the reason for token verification failure back to the
> client
> ------------------------------------------------------------------------------------
>
> Key: KUDU-1925
> URL: https://issues.apache.org/jira/browse/KUDU-1925
> Project: Kudu
> Issue Type: Improvement
> Components: rpc, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Alexey Serbin
>
> When the server tries to verify a client's token, and finds that the token is
> not valid, it should propagate the specific error code back to the client.
> This can help the client know the appropriate action, most notably that it
> can handle an expired token by fetching a new one from the master.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
