Is there a way for gRPC server - Go server specifically, to close the the client stream/connection?

[yz]

I am trying to implement some auth mechanism on go gRPC server. When the auth failed, ideally, the driver should be able to close the client connection. But seems that the ServerStream does not offer an interface to do that. Is it possible to do it in golang?

[Carl Mastrangelo]

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).   

[yz]

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 much more flexible if the framework can offer some hooks when clients connect or disconnect.

[yz]

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 application layer more freedom to handle these clients if the application layer has the access to the transport.

On Wednesday, January 24, 2018 at 8:49:47 AM UTC+8, Carl Mastrangelo wrote:

[Menghan Li]

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.

[yz]

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.  

[Eric Anderson]

On Wed, Jan 24, 2018 at 6:49 PM, 'yz' via grpc.io <grp...@googlegroups.com> 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 on the server.

 I responded on one of your other threads on some issues you will encounter with your "TCP-connection is a session" approach. We can continue the discussion there or here.