You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is not possible to ascertain from an encoded YARPC handler exactly to who the remote peer is.
For example, it would be useful from and audit and debugging point of view to identify which peer is sending malicious, malformed, or otherwise problematic RPCs.
The proposed interface would be to add the string to the transport.Request structure, so an application can be do something like:
Note, the design was chosen to be a string to be as underlying transport (transport being L3/L4) agnostic as possible.
Current workarounds are tightly coupled to the underlying protocol. For example, one can use https://pkg.go.dev/google.golang.org/grpc/peer#FromContext to obtain the peer's net.Addr in a GRPC handler, but there is no trivial equivalent for TChannel and HTTP.
The text was updated successfully, but these errors were encountered:
Currently, it is not possible to ascertain from an encoded YARPC handler exactly to who the remote peer is.
For example, it would be useful from and audit and debugging point of view to identify which peer is sending malicious, malformed, or otherwise problematic RPCs.
The proposed interface would be to add the string to the transport.Request structure, so an application can be do something like:
Note, the design was chosen to be a string to be as underlying transport (transport being L3/L4) agnostic as possible.
Current workarounds are tightly coupled to the underlying protocol. For example, one can use https://pkg.go.dev/google.golang.org/grpc/peer#FromContext to obtain the peer's net.Addr in a GRPC handler, but there is no trivial equivalent for TChannel and HTTP.
The text was updated successfully, but these errors were encountered: