grpc / grpc/grpc

C++ server-side interceptor ability to cancel a call

Open
#28,807 23 comments 3 reactions 2 assignees Claimed by @rishesh007 View on GitHub
kind/enhancement lang/c++ priority/P2
Dominant language
C++
Stars
45.3k
Forks
11.4k
Avg merge
2d 12h
Merged PRs (30d)
47

Description

### Is your feature request related to a problem? Please describe.
I want to do rate limiting in the grpc server for fine grained control. The only way in C++ to block a request before the application callback is invoked is using an AuthMetadataProcessor, however those only have access to the call metadata but no info about the client. Interceptors do have access to the server context (and thus the peer info), however those can not cancel an rpc and are invoked after the metadata processor is done, so passing info using the metadata fields doesn't work either.

### Describe the solution you'd like
Ideally the channel/call information ([which seems to be already available at the call site of AuthMedataProcessor](https://github.com/grpc/grpc/blob/bfd1bcfc094fb2a5c69487b8054239bd994f87e3/src/core/lib/security/transport/server_auth_filter.cc#L235)) is passed into the processor similar to how its done for Interceptors. However since the interface of `Process()` doesn't contain any info class and we can't change it since its public, the best option is probably to add peer info to the auth_metadata similar to `:path` and `:authority`.

### Describe alternatives you've considered
I currently rate limit based on user information which is extracted from the jwt token sent with each rpc. However verifying a jwt has a considerable performance cost and my hope was to rate limit already before that base on peer ip. In addition it would be usefull to log the peer info in case authentication fails, which is simply not possible right now.

### Additional context
Facilities for authentication/authorization in grpc seem to be quite lacking in general for everything except mTLS, which in many cases is not something you need. In particular in my case encryption is not needed since all connections are established via an encrypted vpn anyway. While you obviously dont want to authenticate a client purely based on their IP, having information about the client has a multitude of uses for authentication.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.