[
https://issues.apache.org/jira/browse/ACCUMULO-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569895#comment-13569895
]
Christopher Tubbs commented on ACCUMULO-1028:
---------------------------------------------
I see. Certainly, (String, byte[]) would be least intrusive to the public API,
and (Principal, byte[]) minimally more so.
However, why should it take the already serialized token? That could complicate
user code, because then they have to serialize the token (or rely on the system
that provides the token to do it)... for *our* RPC calls. That doesn't make
sense to me. We don't necessary need a serialized token... we just need to know
how to serialize it, and the implementing class can define that so we don't
have to.
You said above that there's no need for them to follow a strict
serialization/deserialization interface, but you're imposing one anyway (it's
unavoidable), essentially "convertToBytes() and convertFromBytes()". Don't get
me wrong... I've no problem with byte[] as the result of that imposition (in
fact, I think it's necessary for ACCUMULO-1027)... I just don't like seeing
arbitrary byte arrays in the public API... I'd rather do it behind the
scenes... because a byte array could be anything, and you lose all compile time
checks, and I don't think this is user-friendly for an API. We're developing in
a high level language, and we can do better than expressing objects as
non-expressive byte arrays in our API.
You're right about the generics. It doesn't need to be a generic method. The
reason why a generic method is because (I think) it's easier to express to the
user what the method is expecting, but it could just as easily have been:
{code:java}
public Connector getConnector(Principal userPrincipal, AuthToken authToken);
{code}
They both achieve the same thing. (Unless we wanted to return a Connector<T> to
support things like Connectors that automatically renew tokens that expire, or
provide other token manipulation methods, like those in SecurityOperations, in
which case, it would be better to have the generics. I'm not suggesting we do
that, but the current implementation of ACCUMULO-259, without addressing
ACCUMULO-1024 would benefit from it if the generic parameter is passed down to
the Connector's SecurityOperations, so users can get compile-time checks
against using inconsistent token types in the API).
(Note also that I'm using "AuthToken" rather than "SecurityToken", because I
think it better expresses its role, because "security" could mean anything.)
> Distinguish the user principal from the authentication token
> ------------------------------------------------------------
>
> Key: ACCUMULO-1028
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1028
> Project: Accumulo
> Issue Type: Sub-task
> Components: master, tserver
> Reporter: Christopher Tubbs
> Assignee: John Vines
> Fix For: 1.5.0
>
>
> The user principal is something that uniquely identifies a user. An
> authentication token is the item that authenticates the user principal, may
> be temporal, and may vary. It is not clear from the implementation of
> ACCUMULO-259 that these are separate things, and I think it would benefit the
> API to distinguish them.
> It could also simplify the API, for users transitioning from the old
> authentication stuff to the new authentication stuff, because there would be
> a one-to-one mapping with the username/password with which they are familiar:
> {code:java}
> public Connector getConnector(String username, byte[] password);
> {code}
> becomes
> {code:java}
> public <T extends AuthToken> Connector getConnector(Principal userPrincipal,
> T authToken);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
