Thank you Ken, That was exactly what I was looking for!
On Tuesday, November 28, 2017 at 4:50:01 PM UTC-8, Ken Payson wrote: > > I think there are other ways to accomplish what you are describing. > > Insecure channels still support custom metadata, which can be passed to > stubs using the optional "metadata" field. > Here is an example. > <https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/tests/interop/methods.py#L368> > > As Nathaniel mentioned, it is unlikely that credentials will be allowed on > insecure channels given that it was a deliberate restriction. > > > > > On Monday, November 27, 2017 at 3:11:01 PM UTC-8, Rafael Chacon wrote: >> >> Hi Nathaniel, >> >> Wondering if you have a bit of time to think about this. This is an >> outgoing issue for a feature we are working on vitess >> <http://www.vitess.io>. To give you more context, I'm adding a link to >> the Vitess github issue to this thread. >> >> https://github.com/youtube/vitess/pull/3418 >> >> Best, >> >> >> On Fri, Nov 10, 2017 at 3:55 PM, Rafael Chacon <rch...@slack-corp.com> >> wrote: >> >>> Hi Nathaniel, >>> >>> Thank you for your reply. >>> >>> In our deployment we use GRPC only between components that are part of >>> our network, which is secured at a lower layer of the stack. Our general >>> approach is _not_ to require all of our applications to implement transport >>> level security or encryption, as that service is supplied by the network >>> level. >>> >>> However, we would like to extend the GRPC communication to support >>> user-based authentication / authorization which by definition is an >>> application-specific construct. >>> >>> Although I understand that it would be possible for a naive user to leak >>> credentials if they used an insecure channel but used credentials on it, >>> the current implementation stance of python GRPC prevents us from using >>> authorization without an unnecessary (and undesired) level of transport >>> encryption. >>> >>> One proposal we considered to handle this would be to have a "null" >>> channel credentials object -- i.e. make it an obvious decision by the >>> application programmer to use call credentials _without_ channel security. >>> >>> Specifically, the call site would be something like: >>> >>> grpc.composite_channel_credentials( >>> grpc_insecure_channel_credentials(), >>> my_custom_call_credentials() >>> ) >>> >>> On Fri, Nov 10, 2017 at 3:00 PM, Nathaniel Manista <nath...@google.com> >>> wrote: >>> >>>> On Thu, Nov 9, 2017 at 6:13 PM, <rch...@slack-corp.com> wrote: >>>> >>>>> By looking at this thread >>>>> <https://www.mail-archive.com/grpc-io@googlegroups.com/msg01161.html>, >>>>> it seems that the python client requires a secure channel to send >>>>> credentials. >>>>> >>>> >>>> Yes, this was a deliberate decision and I think there's even logic in >>>> gRPC Core to prevent the accidental transmission of clients over unsecured >>>> channels. >>>> >>>> This is not the case in golang (it is an option >>>>> <https://github.com/grpc/grpc-go/blob/master/credentials/credentials.go#L42> >>>>> ). >>>>> >>>>> Is there any workaround in python for this? >>>>> >>>> >>>> There is no currently-supported workaround and... I'm not even sure I >>>> could come up with an unsupported workaround. >>>> >>>> Are there any plans to support it with an interface like the one >>>>> defined in go? >>>>> >>>> >>>> There are no such plans at this time. >>>> >>>> Can you tell us more about your use case? >>>> -Nathaniel >>>> >>> >>> >> -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/9bebfdd5-cc44-4f89-8237-f21aa9ad98bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
