In general, authentication is an application-level control and it would be impossible for Thrift to provide a framework-level silver bullet for all possible kinds of authentication schemes. It is also assumed that Thrift runs in a totally trusted environment where messages can be freely exchanged between a controlled set of machines. For user authenticated requests, it makes more sense to pass some kind of token along with an authenticated API request (as Dave mentions was done in Evernote's API), rather than adding another state layer within Thrift to hold application-level data like authentication tokens.
That being said, the beauty of open source frameworks is that you can both examine and modify what's under the hood to fit your needs. On 17 Apr 2010, at 12:58, Bjørn Borud wrote: > 2010/4/17 Dave Engberg <[email protected]> > >> >> Evernote uses Thrift as the transport for all external (client-service) >> communications. We do an in-bound "authenticationToken" parameter for all >> relevant API calls: >> http://www.evernote.com/about/developer/api/ref/ >> The auth token is received either via a username + password: >> >> http://www.evernote.com/about/developer/api/ref/UserStore.html#Fn_UserStore_authenticate >> Or via OAuth for web services. >> >> > hmm, I see. I kinda suspected as much. > > It would have been nice to be able to tuck away the authentication in the > lower layers and not be forced to clutter up every API with the > authentication stuff. thanks for posting the links to your API docs though. > I will study them with interest :-). > > > -Bjørn
