accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: AccumuloToken
Date Mon, 28 Jan 2013 19:35:41 GMT
That line in the TokenHelper determines what class the Token should be
deserialized as. It has nothing to do with what Authenticator it gets
thrown against.


On Mon, Jan 28, 2013 at 2:17 PM, Eric Newton <eric.newton@gmail.com> wrote:

> Inline
>
>
> On Mon, Jan 28, 2013 at 12:13 PM, John Vines <vines@apache.org> wrote:
>
>> I forgot, but agree that we should try to keep
>> thrift out of the client api. I'm refactoring it now to keep cruft of the
>> client end.
>>
>
> Thanks.
>
>
>> I can rename it to SecurityToken as part of the refactoring.
>>
>
> Great.
>
>
>> We need to keep the AuthInfo floating around for API compatibility. As
>> much
>> as I would love to kill them with fire, this kills api compatibility
>> between versions.
>>
>
> Feel free to sprinkle warning suppression annotations
>
>
>>
>> The security class is not specified by the remote caller, it's
>> instantiated
>> from the configuration xml files. All the client does is provide a token
>> and it's up to the implementation to accept/reject it. I simply provided a
>> mechanism for the client to get a hint as to what type of token is
>> expected.
>>
>
> I beg to differ.  Please see TokenHelper.fromBytes appears to be using
> deserialized information directly to load a class.
>
>
>> However, with the last
>> minute of the proxy, I'm afraid I do not have the time or knowledge of the
>> proxy to get that support in for 1.5.
>>
>
> Keith had an idea.  I'll add a authenticate method that will return a
> token.  The proxy methods will all take tokens.
>
> -Eric
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message