grpc gateway intercepter

[wongoo]

grpc-gateway provide a proxy mechanism , but no proxy intercepter.

A intercepter is a function called before method handler, the intercepter can get info about the definition of the method, like method path and so on.

The following is a scenario to use intercepter and how to design it.

I define a google.protobuf.MethodOptions named allow_roles in all methods, which is used for authorization.
Then it can get a map whoes key is the full path of method, and value is the defined allow roles.

I think the authorization can be done in grpc-gateway.

First, add method path into handler and provide it when registering.

type handler struct {
	pat     Pattern
	method  string    // <--------the full path of method /pkg.ServiceName/MethodName
	h       HandlerFunc
}

Second, add intercepter in ServeMux and provide method to initial it.

type ServeMux struct {
	// handlers maps HTTP method to a list of handlers.
	handlers               map[string][]handler
	forwardResponseOptions []func(context.Context, http.ResponseWriter, proto.Message) error
	marshalers             marshalerRegistry
	incomingHeaderMatcher  HeaderMatcherFunc
	outgoingHeaderMatcher  HeaderMatcherFunc
	metadataAnnotators     []func(context.Context, *http.Request) metadata.MD
	protoErrorHandler      ProtoErrorHandlerFunc
	intercepter            func(context.Context,http.ResponseWriter, *http.Request, method string) error  // <----- add intercepter definition
}

Third, call intercepter before calling handler:

for _, h := range s.handlers[r.Method] {
	pathParams, err := h.pat.Match(components, verb)
	if err != nil {
		continue
	}
	//-------------------------
	if s.intercepter != nil {
	  err = intercepter(ctx, w, r, h.method) //  <----------- call intercepter before calling handler
	  if err != nil {
		//TODO HANDLE ERROR
		return
	  }
	}
	//-------------------------

	h.h(w, r, pathParams)
	return
}

[achew22]

I think you can achieve this today without writing anything new in grpc-gateway by using eitehr a grpc client interceptor or a server interceptor in the destination server. Can you help me understand why this needs to be added to the routing framework over hooking into the preexisting interceptors?

[wongoo]

@achew22 I want to do authorization for requests only in apigateway , and grpc client interceptor can do that. It's what I'm looking for. So it's not needed add intercepter in apigateway. Thanks!

[achew22]

@wongoo Perfect! Thanks so much for following up. Would you be willing to write a little bit up? If so, we could put it as a FAQ in our documentation so that future users won't have to struggle quite as much. What do you think of that?

[wongoo]

Do authorization for requests in apigateway instead of grpc servers is more efficient , especially when grpc servers calling each others.

Grpc client interceptor is a way to implement authorization, but it's called after the restful request proxied to grpc request. If the authorization can be done before proxying, performance maybe better.
@achew22 what do u think?

[johanbrandhorst]

Personally the gateway seems the wrong place to add interceptors. It performs translation, not business logic. All of this belongs in the gRPC service it's talking to.

[wongoo]

@johanbrandhorst may be call it business apigateway, consider it as part of business. And aws apigatway also has authorization in it.