On Mon, Jan 28, 2013 at 12:13 PM, John Vines <[email protected]> wrote: > inline- > > > On Mon, Jan 28, 2013 at 10:18 AM, Eric Newton <[email protected]> wrote: > >> I'm having some problems with AccumuloToken. Christopher has already >> brought it up in IRC, and I agree. I'm putting it out on the list for a >> more inclusive discussion. >> >> I don't like exposing thrift as the serialization mechanism. In >> particular, this just hurts my eyes: >> >> public interface AccumuloToken >> <T extends TBase<?,?>, F extends TFieldIdEnum> extends TBase<T, F>, >> Destroyable { >> ... >> } >> >> Is there some reason this is not just: >> >> public interface AccumuloToken extends Writable, Destroyable { >> ... >> } >> >> I've switched this in my local development environment and it seems to work >> just fine. >> > > > This works because the tokens we provide still implement TBase, and the > Thrift serdes still work. 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. > > >> >> I don't like the class name. Is there some reason why Accumulo isn't just >> assumed and we call this Token or Credential, or even SecurityToken? >> >> > I can rename it to SecurityToken as part of the refactoring. > > >> I don't like the rest of the code being littered with deprecation warnings. >> If we're not willing to switch the code over to The New Way, why should we >> expect our users? >> >> > 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. > > >> Are there not some security implications of dynamic class loading for >> authorization when the class name is specified *by the remote caller*? >> >> > 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. > > >> And I know a punched the Proxy in at the last second, but is there >> something we should do with security to avoid changes to this new API? >> >> > Like with the CLI and shell, the proxy only supports UserPassTokens. This > should cover a large majority of use cases, but you never know. However, > the great part about extensibility is it allows individuals to do what they > need to do if it reaches outside the common cases. In the worse case, they > can wrap whatever token they need into UserPass to fit their needs, but in > an ideal world we should be able to work with these. 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.
I can take a look at this. We are not going to be adding any new features for 1.5. But I think we should certainly intergrate the exiting new features to form a cohesive whole. I have one idea for this. I will post it on the ticket. > > >> -Eric >>
