On Wed, Jan 24, 2018 at 6:49 PM, 'yz' via grpc.io
wrote:
> Thanks Menghan for the suggestion, but seems it does not fit our scenario
> well. I noticed that and the cred config is server-wise. What we want to
> achieve is to do the auth in an interceptor, so that it is configurable per
> endpoint
Thanks Menghan for the suggestion, but seems it does not fit our scenario
well. I noticed that and the cred config is server-wise. What we want to
achieve is to do the auth in an interceptor, so that it is configurable per
endpoint on the server.
On Thursday, January 25, 2018 at 3:17:18 AM U
For connection level auth, if the ServerHandshake() function returns an
error, the connection will be closed by the server:
https://github.com/grpc/grpc-go/blob/82e9f61ddde02833789fdca2123b576151db8654/server.go#L565
There's currently no way to close the connection in the RPC handler.
--
You r
Another thing I want to mention is that the clients might not be as
friendly as you think, which means that it will not behave as you expected.
If the auth failed, the client do not have to "go away", they can still
try to send more requests to the server for bad purposes. It will give the
ap
Thanks for your answer, but I do not get why auth has to be per-RPC. If the
client connect to the server and has been authed for the first time, the
server should know that the connection has been authenticated, and there is
no need to authenticate this RPC again. Actually, I think it will be mu
Generally auth is a per RPC idea, rather than a per connection idea.
Connections are automatically shutdown after some time in the event the
client goes away (say, after failing to auth for instance).
On Monday, January 22, 2018 at 7:16:53 PM UTC-8, yz wrote:
>
> I am trying to implement som
