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 > <javascript:>> 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 >> <javascript:>> wrote: >> >>> On Thu, Nov 9, 2017 at 6:13 PM, <rch...@slack-corp.com <javascript:>> >>> 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/ffa39500-bb66-408a-b322-e3c2b2f1b710%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
