[Grpc-java] How to pass something from ServerInterceptor to service method?

[Young You]

I have tried to use ServerInterrceptor to implement a token auth. But after verify, I cannot pass the userid to the service, how to do it?

[Eric Anderson]

Use a ThreadLocal. grpc-java 0.12.0 will be released very soon which will have some integration with io.grpc.Context, which has some advantages over a simple ThreadLocal, so that is an option as well.

We will be improving the patterns, especially for auth, over time with Context at the core.

On Thu, Jan 14, 2016 at 7:07 PM, Young You <youngy...@gmail.com> wrote:

I have tried to use ServerInterrceptor to implement a token auth. But after verify, I cannot pass the userid to the service, how to do it?

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/130cfbc1-6bb7-4781-b896-e666a2ab380c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Young You]

Thank you for your reply. I have found that and expect for the new version.

在 2016年1月20日星期三 UTC+8上午8:02:40，Eric Anderson写道：

Use a ThreadLocal. grpc-java 0.12.0 will be released very soon which will have some integration with io.grpc.Context, which has some advantages over a simple ThreadLocal, so that is an option as well.

We will be improving the patterns, especially for auth, over time with Context at the core.

On Thu, Jan 14, 2016 at 7:07 PM, Young You <youngy...@gmail.com> wrote:

I have tried to use ServerInterrceptor to implement a token auth. But after verify, I cannot pass the userid to the service, how to do it?

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[Eric Anderson]

Oh, and a bit of a gotcha I forgot to mention (but a similar question on IRC made me think of): each callback may occur on a different thread, so you really have to set the thread-local per-callback.

That's a can be bit annoying, but mainly just with boilerplate. However, when using Context we have a helper function (in the coming 0.12.0) Contexts.interceptCall() which should be just what you need. 

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/7a49a4de-955e-4671-98e2-88057f803fb4%40googlegroups.com.

[gpe...@gmail.com]

sorry, i have confuse with the Context usage. 

for some situation, when i want to pass the header, should i use the code like these code below within the server interceptor.

return Contexts.interceptCall(Context.current().withValue(Context.key("header"), requestHeaders), method,

new SimpleForwardingServerCall<RespT>(call) {

@Override

public void sendHeaders(Metadata responseHeaders) {

responseHeaders.put(customHeadKey, "customRespondValue");

super.sendHeaders(responseHeaders);

}

}, requestHeaders, next);

and should i release this new context when call done, like deatach etc.

在 2016年1月20日星期三 UTC+8上午8:02:40，Eric Anderson写道：

Use a ThreadLocal. grpc-java 0.12.0 will be released very soon which will have some integration with io.grpc.Context, which has some advantages over a simple ThreadLocal, so that is an option as well.

We will be improving the patterns, especially for auth, over time with Context at the core.

On Thu, Jan 14, 2016 at 7:07 PM, Young You <youngy...@gmail.com> wrote:

I have tried to use ServerInterrceptor to implement a token auth. But after verify, I cannot pass the userid to the service, how to do it?

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[Eric Anderson]

On Sun, Jun 5, 2016 at 11:28 PM, <gpe...@gmail.com> wrote:

sorry, i have confuse with the Context usage. 

for some situation, when i want to pass the header, should i use the code like these code below within the server interceptor.

From the code it looks like nothing uses the requestHeaders. If that's being done elsewhere are not shown here, that's fine (it's just a little strange to see the mixing of using Context and modifying responseHeaders, since those seem unrelated).

return Contexts.interceptCall(Context.current().withValue(Context.key("header"), requestHeaders), method,

new SimpleForwardingServerCall<RespT>(call) {

@Override

public void sendHeaders(Metadata responseHeaders) {

responseHeaders.put(customHeadKey, "customRespondValue");

super.sendHeaders(responseHeaders);

}

}, requestHeaders, next);

and should i release this new context when call done, like deatach etc.

The code looks fine as-is, with regard to Context. interceptCall makes sure to set and unset the Context before/after each call.

在 2016年1月20日星期三 UTC+8上午8:02:40，Eric Anderson写道：

Use a ThreadLocal. grpc-java 0.12.0 will be released very soon which will have some integration with io.grpc.Context, which has some advantages over a simple ThreadLocal, so that is an option as well.

We will be improving the patterns, especially for auth, over time with Context at the core.

On Thu, Jan 14, 2016 at 7:07 PM, Young You <youngy...@gmail.com> wrote:

I have tried to use ServerInterrceptor to implement a token auth. But after verify, I cannot pass the userid to the service, how to do it?

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/130cfbc1-6bb7-4781-b896-e666a2ab380c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/12768840-5927-4309-9e8a-fb064c7d944c%40googlegroups.com.

[gpe...@gmail.com]

Sorry, My purpose is to pass the session id from request headers to service handler in such pattern.  it is not about the response header modify.

@Override

public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(MethodDescriptor<ReqT, RespT> method,

ServerCall<RespT> call, final Metadata requestHeaders, ServerCallHandler<ReqT, RespT> next) {

return Contexts.interceptCall(Context.current().withValue(subject, sessionId)........

@Override

public void testCall(Empty request, StreamObserver<Empty> responseObserver) {

Object sessionId = ServerInterceptor.subject.get();

在 2016年6月7日星期二 UTC+8上午3:13:42，Eric Anderson写道：

[Eric Anderson]

On Tue, Jun 7, 2016 at 7:37 AM, <gpe...@gmail.com> wrote:

Sorry, My purpose is to pass the session id from request headers to service handler in such pattern.  it is not about the response header modify.

@Override

public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(MethodDescriptor<ReqT, RespT> method,

ServerCall<RespT> call, final Metadata requestHeaders, ServerCallHandler<ReqT, RespT> next) {

return Contexts.interceptCall(Context.current().withValue(subject, sessionId)........

It still looks fine (and the usage you had as well). And you wouldn't need to create your own call:

return Contexts.interceptCall(

    Context.current().withValue(subject, sessionId),

    method, call, requestHeaders, next);

[gpe...@gmail.com]

Thanks.

在 2016年6月7日星期二 UTC+8下午11:35:05，Eric Anderson写道：

[Young You]

I have met some similar problem using 0.14.

If I use  `Contexts.interceptCall(Context.current().withValue(Context.key("user"), info), method, call, metadata, next); `, it can't find the right data.

I find out that if I call `Context.key("user")` twice, then return different value, which means they are two different keys. So, I persist the key created with `Context.key("user")`, and get data with it every time and it works.

I hope that would be useful for you.

On Mon, Nov 14, 2016 at 9:16 PM <ban...@gmail.com> wrote:

hi ,do you get the right place to pass the context?

i use same code and did't work out , because this code Context.current().withValue(subject, sessionId) ,

withValue will create a new Context as his sub-Context,  so the sessionId is being set into this sub-Context, if you Key.get() in the service method , sub-Context wont be looked up.

is this right way to get the context info?

在 2016年6月7日星期二 UTC+8下午11:35:05，Eric Anderson写道：

On Tue, Jun 7, 2016 at 7:37 AM, <gpe...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/oO2NtpIzRbM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.

Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/259c8941-62f7-42d7-aee8-1ca7fa904031%40googlegroups.com.