Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> AccumuloToken


Copy link to this message
-
Re: AccumuloToken
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>wrote:
>>
>>> Inline
>>>
>>>
>>> On Mon, Jan 28, 2013 at 12:13 PM, John Vines <[EMAIL PROTECTED]> 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
>>>
>>
>>
>