Hi all, I'm trying to build an auth flow (email + OTP -> JWT) between a 
grpc-web client and a grpc-java server, with an Envoy proxy between the 
two. Just to make sure I'm not missing anything big, this is my mental 
image of how I think RPC calls are handled on the server, with a 
ServerInterceptor attached. 
   
   1. ServerInterceptor#interceptCall to wrap the real call in a 
   CustomServerCall
   2. CustomServerCall#sendHeaders to build and return response headers
   3. CustomServerCall#sendMessage to build and return response body
   4. CustomServerCall#close to set final status, response trailers, etc.
   5. Response headers are converted to HTTP response headers when sent 
   back to the gRPC web client. Response trailers look like they are only part 
   of the gRPC payload, but they don't get handled by the browser.

I'm under the impression that with this pattern, the response headers are 
always built and sent before the RPC call actually starts. This makes me 
think there's no access to the request body when constructing response 
headers.

My workaround is: 
   
   1. Attach a username + password as request *headers*, instead of in the 
   request body.
   2. Convert username + password into a JWT in 
   CustomServerCall#sendHeaders, and include a set-cookie header
   3. The actual body of the server call is a no-op.

This workaround sounds like a misuse of the API, so I wanted to see what 
your thoughts were.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/712f96ff-4a78-48a9-b00c-84fa0f75dbban%40googlegroups.com.

Reply via email to