[jira] [Updated] (THRIFT-5104) Forwarding callContext into methods of handler as very last parameter

["Nikolay Rapotkin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikolay Rapotkin updated THRIFT-5104:
-------------------------------------
    Patch Info:   (was: Patch Available)

> Forwarding callContext into methods of handler as very last parameter
> ---------------------------------------------------------------------
>
>                 Key: THRIFT-5104
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5104
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C++ - Compiler, C++ - Library
>            Reporter: Nikolay Rapotkin
>            Priority: Major
>              Labels: ready-to-commit
>
> I faced with common issue: I want be able to check if sender is a authorized user and to know who she/he is. I Decided to provide some heads to every single call by Injecting authorization token. For this purpose i made a ProtocolWrapper that do stuff like the following:
> {code:java}
> uint32_t ProtocolWrapper ::writeMessageBegin_virt(const std::string& name, const MessageType type, const int32_t seqid)
> {
>   auto size = TProtocolDecorator::writeMessageBegin_virt(name, type, seqid);
>   if (type == MessageType::T_CALL || type == MessageType::T_ONEWAY)
>     size += TProtocolDecorator::writeString(token);
>   
>   return size;
> }
> {code}
>  
> Then It's needed to process request , take out this authorization token, change it on user information and provide access to it inside methods of a heandler.
> Taking out authorization token from data stream is pretty easy to do. For instance TMultiplexProcessor does the same stuff. Or there is even a better way - providing a ProcessorEventHandler which operates callContext which can do this work.
> But the accessing taken data inside methods of a handler appeared a very difficult thing because callContext CAN NOT really influence on a method call or method arguments!
> So, the idea is to generate a handler interface which can take callContext of Processor for it's direct access.
>  
> For example from this thrift service definition
>  
> {code:java}
> service SomeService {
>   void someMethod(),
>   void anotherMethod(
>    1: int value,
>   ),
> }
> {code}
> would generate the following code:
>  
>  
> {code:java}
> class SomeServiceIf {
> public:
>   virtual ~SomeServiceIf() {}
>   virtual void someMethod() = 0;             // usual
>   virtual void anotherMethod(int value) = 0; // methods
>   // virtual methods but
>   // with default implementation
>   // for backward compatibility
>   virtual void someMethod(void* ctx) {
>     someMethod();
>   }
>   virtual void anotherMethod(int value, void* ctx) {
>      anotherMethod(value);
>   }
> }
> {code}
>  
>  
> This requires small change in a SomeServiceProcessor. It should call method with context.
> But this change wont break an existing code because of forwarding calls to non-context methods by default.
> Does it make any sense or there is a better way to do what I want?
>  
> you can look at prototype of this change in [my fork|https://github.com/Rapotkinnik/thrift/tree/feature/cpp/callcontext-forwarding-to-handler]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)