-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible to retrieve peer info? #357
Comments
Currently, it's possible but not super-simple. You'd need to write a small piece of I'm open to exposing this in handlers with an easier-to-use API, but I'd like to see what else people expect to do with this information. For example, we don't have any current plans to expose an equivalent to the |
Some potential usages I can think of include per IP rate limiting, caching, or naive authorization. It might be nicer to include it in the request object like the headers are. It makes them more explicit, less magical, and easier to use. |
A middleware like @akshayjshah suggested indeed works for anyone who comes across this issue. This is how I implemented it: type remoteAddrKey struct{}
func addRemoteAddr(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := context.WithValue(r.Context(), remoteAddrKey{}, r.RemoteAddr)
next.ServeHTTP(w, r.WithContext(ctx))
})
} Make sure you wrap your handler in the middleware (like any other HTTP middleware in Go): mux.Handle(path, addRemoteAddr(handler)) And then in your handler: remoteAddr, ok := ctx.Value(remoteAddrKey{}).(string) |
But besides the option above, is there a way to get the remote address without the middleware? I saw the IP address is already in the context when I was playing around with my debugger but I just didn't get to a point of figuring out how to extract it. |
Nothing in |
On requests and streams, expose the peer's address. For clients, the address is the host or host:port, parsed from the URL. For servers, the address is an IP:port pair, provided by `net/http` as `Request.RemoteAddr`. In #357, a handful of users asked for this information for logging, per-IP rate limiting, and a variety of other server-side concerns. It's also necessary for OpenTelemetry interceptors (#344). Fixes #357.
On requests and streams, expose the peer's address. For clients, the address is the host or host:port, parsed from the URL. For servers, the address is an IP:port pair, provided by `net/http` as `Request.RemoteAddr`. In #357, a handful of users asked for this information for logging, per-IP rate limiting, and a variety of other server-side concerns. It's also necessary for OpenTelemetry interceptors (#344). Fixes #357.
Opened a PR that exposes this info on Usage looks like this: type PingServer struct {}
func (p *PingServer) Ping(
ctx context.Context,
request *connect.Request[pingv1.PingRequest],
) (*connect.Response[pingv1.PingResponse], error) {
fmt.Println(request.Peer().Addr) // <-- this is new!
return connect.NewResponse(&pingv1.PingResponse{
Number: request.Msg.Number,
}), nil
} |
* Add Spec to some user-facing streams Where the generated code replaces Request with a stream, expose the Spec. * Expose peer information to servers and clients On requests and streams, expose the peer's address. For clients, the address is the host or host:port, parsed from the URL. For servers, the address is an IP:port pair, provided by `net/http` as `Request.RemoteAddr`. In #357, a handful of users asked for this information for logging, per-IP rate limiting, and a variety of other server-side concerns. It's also necessary for OpenTelemetry interceptors (#344). Fixes #357.
Released in v0.5.0! |
* Add Spec to some user-facing streams Where the generated code replaces Request with a stream, expose the Spec. * Expose peer information to servers and clients On requests and streams, expose the peer's address. For clients, the address is the host or host:port, parsed from the URL. For servers, the address is an IP:port pair, provided by `net/http` as `Request.RemoteAddr`. In #357, a handful of users asked for this information for logging, per-IP rate limiting, and a variety of other server-side concerns. It's also necessary for OpenTelemetry interceptors (#344). Fixes #357.
With
grpc-go
I can get peer info like so:Is it possible to do this with
connect-go
?I am trying to get the IP that the request is originating from.
Thanks
The text was updated successfully, but these errors were encountered: