Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
MIME-Version: 1.0
From: "James E. King, III" <jking@apache.org>
Date: Tue, 28 Mar 2017 12:36:22 -0400
Message-ID: <CAOWZHxcWo5rRea23A8iapm9RynGs+FpvfLPiuRNrT7bAnumr2A@mail.gmail.com>
Subject: Re: multitenancy
To: dev@thrift.apache.org
Content-Type: multipart/alternative; boundary=001a114728986edae3054bcd0f13
archived-at: Tue, 28 Mar 2017 16:36:27 -0000

--001a114728986edae3054bcd0f13
Content-Type: text/plain; charset=UTF-8

Thrift has no concept of users or stateful sessions.  While clients can
connect to a server and issue multiple commands, each command is
independent as no identifying information about the connection is sent to
the handler.  Anything like user sessions would need to be handled at a
layer above Thrift, using something analogous to cookies in a web browser.
In the past when I have had to do this in a Thrift IDL, I needed to add
another parameter to every method to carry state from the client to the
server, and I needed to add a method just to generate that session/state
token.

There may already be a Jira ticket for an enhancement to Thrift to add the
capability to have stateful sessions.  For example in the C++
implementation it would be possible to modify the TConnectedClient class
and assign a GUID to each connected client and put it into thread local
storage.  Then any handler would be able to ask thread local storage for
the unique connection ID.  This would only be valid for the duration of a
connected client, however.

I often thought this would work well with the Multiplexed Protocol.  One
could put an authentication API on one channel, and then one could
selectively enable other channels based on the permissions of the user.
All of these ideas I discussed however are just ideas, and not part of the
Thrift project today.

- Jim

--001a114728986edae3054bcd0f13--