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:52:24 GMT
Valid point, did not consider that. Another option, which I feel like an
idiot for not thinking of previously (and would also remedy the proxy
issue), is to switch to JSON (preferred), XML, protobuff, etc. blobs. Then
it switches from the user knowing what token class to invoke to what fields
need to be provided.


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

> Right, but it would allow a malicious user to expand into a class with a
> malicious readFields, or deserialize method.
>
> -Eric
>
>
>
> On Mon, Jan 28, 2013 at 2:35 PM, John Vines <vines@apache.org> wrote:
>
>> 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