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
